On Feb 1, 2009, at 6:14 PM, John Rakestraw wrote:
> Hi --
>
> I'm eager to use the TODO dependencies feature, but I can't make it
> work. In my usual set-up, I (think I) have it set up correctly. (C-h
> C-v indicates that org-enforce-todo-dependencies is set to t.)
> However,
> the dependency simply isn't enforced. Nor is the "ordered" dependency
> enforced.
>
> I understand that it's likely a problem in my set-up, but I don't know
> where to check. However, after hours (literally -- yes, I'm a slow
> learner), I discovered what I hope is a clue to someone more
> knowledgeable than I. Given this simple test file:
>
> ++++++++++++++++++++
> #+ARCHIVE: archive_cndls.org::* Finished Tasks and Projects
> #+SEQ_TODO: TODO STARTED DELEGATED AGENDA WATCH READ APPT | DONE \
> DEFERRED CANCELED WAITING MAYBE
> #+TAGS: Placeholder(p) ATProgram(A) FacProgramming(F) ULI(U)Grants(G)\
> Consultations (C) Supervisions(S) Misc(M) Teaching(T) ExCo(E)
> #+STARTUP: lognotestate
> #+Category: CNDLS
> #+ARCHIVE: archive_cndls.org::
> #+LaTeX_CLASS: report
> # Time-stamp: <2009-02-01 11:26:41 jrake>
>
> * TODO Main task
> :PROPERTIES:
> :ORDERED: t
> :END:
>
> ** TODO Subtask 1
>
> ** TODO Subtask 2
> +++++++++++++++++++++
>
> Dependencies work in one instance (#2 below), but they don't work in
> instances 1 and 3 --
>
> 1. If I start emacs/org-mode with a minimal configuration and
> then open this file, dependencies still don't work.
>
> 2. If I start emacs/org-mode with a minimal configuration, open
> this file, then delete the header line beginning "#+SEQ_TODO"
> and refresh the settings, dependencies work.
>
> 3. If I start emacs/org-mode with my usual configuration,
> dependencies still don't work in this simple test file, even
> if I delete the SEQ_TODO line in its header.
>
> I set up my TODO list in each file, and there's no general set-up for
> these in my ordinary configuration. Any clues where else I should
> look?
What is the value of org-blocker-hook?
- Carsten
A clarification re this part of my initial message:
> 2. If I start emacs/org-mode with a minimal configuration, open
> this file, then delete the header line beginning "#+SEQ_TODO"
> and refresh the settings, dependencies work.
This is misleading. I realized that dependencies *do* work consistently
in the minimal configuration. With the header line in the test file, I
can change the main task from TODO to STARTED (or to any of the other
non-done states), but I'm blocked from changing it to DONE.
But they still don't work with my usual configuration.
Apologies.
--John
On Sun, 1 Feb 2009 19:03:46 +0100 Carsten Dominik <dominik@science.uva.nl> wrote: > > This is misleading. I realized that dependencies *do* work > > consistently > > in the minimal configuration. With the header line in the test > > file, I can change the main task from TODO to STARTED (or to any of > > the other non-done states), but I'm blocked from changing it to > > DONE. > > This is how it should be. I agree -- that's why I apologized for introducing that point. > > > But they still don't work with my usual configuration. > > Well, if the value of org-blocker-hook is nil in this case, I > am not surprised! Why is it nil? If you set the > org-enforce... variables, the hook should be filled > with the two functions. I don't know why it's nil. However, I've discovered a bit more. It seems that the problem is that my settings in my org-config file: (setq org-enforce-todo-dependencies t) (setq org-agenda-dim-blocked-tasks 'invisible) (setq org-enforce-todo-checkbox-dependencies t) didn't prompt the required change in the value of org-blocker-hook. With these lines in my org config file, the values of the three variables are as expected, but the value of org-blocker-hook remains nil, even if I stop and re-start emacs. When I change the value of org-enforce-todo-dependencies using customize, then the value of org-blocker-hook is what it should be, and the dependencies work, even if I stop and re-start emacs. So presumably something else in my config file is keeping org-blocker-hook from being re-set? I'd prefer not to use the customize function, so I'd hoped to set it in my config file. Thanks, and apologies for not sorting through this a bit more before the initial post. --John
On Feb 1, 2009, at 7:23 PM, John Rakestraw wrote: > On Sun, 1 Feb 2009 19:03:46 +0100 > Carsten Dominik <dominik@science.uva.nl> wrote: > >>> This is misleading. I realized that dependencies *do* work >>> consistently >>> in the minimal configuration. With the header line in the test >>> file, I can change the main task from TODO to STARTED (or to any of >>> the other non-done states), but I'm blocked from changing it to >>> DONE. >> >> This is how it should be. > > I agree -- that's why I apologized for introducing that point. >> >>> But they still don't work with my usual configuration. >> >> Well, if the value of org-blocker-hook is nil in this case, I >> am not surprised! Why is it nil? If you set the >> org-enforce... variables, the hook should be filled >> with the two functions. > > I don't know why it's nil. However, I've discovered a bit more. It > seems that the problem is that my settings in my org-config file: > > (setq org-enforce-todo-dependencies t) > (setq org-agenda-dim-blocked-tasks 'invisible) > (setq org-enforce-todo-checkbox-dependencies t) > > didn't prompt the required change in the value of org-blocker-hook. > With these lines in my org config file, the values of the three > variables are as expected, but the value of org-blocker-hook remains > nil, even if I stop and re-start emacs. You need to set these variables before org.el is loaded. - Carsten > > > When I change the value of org-enforce-todo-dependencies using > customize, then the value of org-blocker-hook is what it should be, > and > the dependencies work, even if I stop and re-start emacs. > > So presumably something else in my config file is keeping > org-blocker-hook from being re-set? > > I'd prefer not to use the customize function, so I'd hoped to set it > in > my config file. > > Thanks, and apologies for not sorting through this a bit more before > the initial post. > > --John > >
In fact, we need a FAQ about this issue:
Several variables in Org must already be set a load time.
This is one of the reasons why you should not use (require 'org)
in your setup, but better only (require 'org-install).
However, org.el will also get loaded when you require some
other org-... file, for example an add-on from the contrib
directory.
The right way is therefore *always* this (a general Emacs truth).
First, set all your variables. Then load the package.
In this particular example, the problem is the following:
Setting the variables for the todo dependencies triggers
adding functions to org-blocker-hook, at load time for org.el.
I *could* do a different implementation, where the functions
are always in the blocker hook, but are only active when the
variables are set. However, the problem is then that it is
difficult to see from the outside if the hook is doing something,
and I want to use that knowledge to avoid overhead in the
agenda for people who do not use todo dependencies.
- Carsten
On Feb 1, 2009, at 8:21 PM, Carsten Dominik wrote:
>
> On Feb 1, 2009, at 7:23 PM, John Rakestraw wrote:
>
>> On Sun, 1 Feb 2009 19:03:46 +0100
>> Carsten Dominik <dominik@science.uva.nl> wrote:
>>
>>>> This is misleading. I realized that dependencies *do* work
>>>> consistently
>>>> in the minimal configuration. With the header line in the test
>>>> file, I can change the main task from TODO to STARTED (or to any of
>>>> the other non-done states), but I'm blocked from changing it to
>>>> DONE.
>>>
>>> This is how it should be.
>>
>> I agree -- that's why I apologized for introducing that point.
>>>
>>>> But they still don't work with my usual configuration.
>>>
>>> Well, if the value of org-blocker-hook is nil in this case, I
>>> am not surprised! Why is it nil? If you set the
>>> org-enforce... variables, the hook should be filled
>>> with the two functions.
>>
>> I don't know why it's nil. However, I've discovered a bit more. It
>> seems that the problem is that my settings in my org-config file:
>>
>> (setq org-enforce-todo-dependencies t)
>> (setq org-agenda-dim-blocked-tasks 'invisible)
>> (setq org-enforce-todo-checkbox-dependencies t)
>>
>> didn't prompt the required change in the value of org-blocker-hook.
>> With these lines in my org config file, the values of the three
>> variables are as expected, but the value of org-blocker-hook remains
>> nil, even if I stop and re-start emacs.
>
> You need to set these variables before org.el is loaded.
>
> - Carsten
>
>
>>
>>
>> When I change the value of org-enforce-todo-dependencies using
>> customize, then the value of org-blocker-hook is what it should be,
>> and
>> the dependencies work, even if I stop and re-start emacs.
>>
>> So presumably something else in my config file is keeping
>> org-blocker-hook from being re-set?
>>
>> I'd prefer not to use the customize function, so I'd hoped to set
>> it in
>> my config file.
>>
>> Thanks, and apologies for not sorting through this a bit more before
>> the initial post.
>>
>> --John
>>
>>
>
Hi Carsten --
Thanks for the troubleshooting, and thanks also for this write-up. In
particular ---
> However, org.el will also get loaded when you require some
> other org-... file, for example an add-on from the contrib
> directory.
I was setting the variables before (require 'org-install), but I found
an earlier instance of (require 'org-xxx). It's inspired me to clean up
and organize my init files.
--John
Carsten Dominik <dominik@science.uva.nl> writes:
> In fact, we need a FAQ about this issue:
>
> Several variables in Org must already be set a load time.
> This is one of the reasons why you should not use (require 'org)
> in your setup, but better only (require 'org-install).
>
> However, org.el will also get loaded when you require some
> other org-... file, for example an add-on from the contrib
> directory.
>
> The right way is therefore *always* this (a general Emacs truth).
>
> First, set all your variables. Then load the package.
>
> In this particular example, the problem is the following:
> Setting the variables for the todo dependencies triggers
> adding functions to org-blocker-hook, at load time for org.el.
>
> I *could* do a different implementation, where the functions
> are always in the blocker hook, but are only active when the
> variables are set. However, the problem is then that it is
> difficult to see from the outside if the hook is doing something,
> and I want to use that knowledge to avoid overhead in the
> agenda for people who do not use todo dependencies.
>
> - Carsten
Excellent, I was wondering why I couldn't get this function to work.
Paul
>>>>> On Sun, 1 Feb 2009 20:38:21 +0100, Carsten Dominik <dominik@science.uva.nl> said:
CD> I *could* do a different implementation, where the functions
CD> are always in the blocker hook, but are only active when the
CD> variables are set. However, the problem is then that it is
CD> difficult to see from the outside if the hook is doing something,
CD> and I want to use that knowledge to avoid overhead in the
CD> agenda for people who do not use todo dependencies.
FYI, I'd actually suggest this approach. I think the number of people
that will get confused by variable-and-loading-ordering will be far
greater than the number of people trying to figure out why the function
isn't doing anything (especially if in the function documentation it
says a variable must be set for it to perform any actions).
I too immediately tried the new TODO dependencies after the last release
announcement and couldn't get it to work... Old habit of performing
'(require ...)' ahead of the variable settings.
--
"In the bathtub of history the truth is harder to hold than the soap,
and much more difficult to find." -- Terry Pratchett
On Feb 2, 2009, at 5:05 PM, Wes Hardaker wrote: >>>>>> On Sun, 1 Feb 2009 20:38:21 +0100, Carsten Dominik <dominik@science.uva.nl >>>>>> > said: > > CD> I *could* do a different implementation, where the functions > CD> are always in the blocker hook, but are only active when the > CD> variables are set. However, the problem is then that it is > CD> difficult to see from the outside if the hook is doing something, > CD> and I want to use that knowledge to avoid overhead in the > CD> agenda for people who do not use todo dependencies. > > FYI, I'd actually suggest this approach. I think the number of people > that will get confused by variable-and-loading-ordering will be far > greater than the number of people trying to figure out why the > function > isn't doing anything (especially if in the function documentation it > says a variable must be set for it to perform any actions). > > I too immediately tried the new TODO dependencies after the last > release > announcement and couldn't get it to work... Old habit of performing > '(require ...)' ahead of the variable settings. I don't think this is easily possible in all cases, but I have made this chance now for the dependency variables. Causes some overhead when entering org-mode, but only trivial. But there are more such variables, org-replace-disputed-keys org-tab-follows-link org-return-follows-link org-mouse-1-follows-link These all have to do with keymaps I am setting up al load time. - Carsten > > -- > "In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett
>>>>> On Mon, 2 Feb 2009 22:08:55 +0100, Carsten Dominik <dominik@science.uva.nl> said:
CD> org-tab-follows-link
And *that* explains one of my other issues!
Thanks!
--
"In the bathtub of history the truth is harder to hold than the soap,
and much more difficult to find." -- Terry Pratchett