emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] Re: TODO state change from TODO to DONE blocked


From: Sébastien Vauban
Subject: [O] Re: TODO state change from TODO to DONE blocked
Date: Fri, 04 Mar 2011 16:01:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (windows-nt)

Hi Bastien,

Bastien wrote:
>>> I've a really weird exception occurring: change state from TODO to DONE is
>>> blocked... while I'm on a leaf of the Org tree!?
>>>
>>> Debugger entered--Lisp error: (error #("TODO state change from TODO to
>>> DONE blocked" 23 27 (face org-todo) 31 35 (face org-done)))
>
> Are you using `org-blocker-hook' or `org-trigger-hook'?

Nope. Never heard of them.

> Maybe you can try to `edebug-defun' the `org-todo' function and follow it's
> execution step by step.

Did it, but not obvious to follow -- I don't talk of the code itself, but of
my edebug skills.

> Let us know.

Though, hopping from one variable description to another, I remembered that I
had set the variable =org-enforce-todo-dependencies= to =t=. Trying to set it
to =nil= made the problem disappear... So, it was a bit narrowed.

I could see in the description of that var that it could block state change if
tasks were ordered and a previous one not done. But I never use the ordered
property.

... Well, never, but well in that parent tree. Was it for test purpose?  Did I
have something else in mind?  I dunno anymore, but that property was
definitely the culprit.

Doing so, I'm wondering:

- if the output message could be updated to make it clear what the reason is,
  or can be?

- why it allowed me to update the tasks state when I narrowed the buffer to
  that task only? Does that mean that *narrowing* somehow *drops the inherited
  properties*?

Anyway, my fault...

Best regards,
  Seb

-- 
Sébastien Vauban




reply via email to

[Prev in Thread] Current Thread [Next in Thread]