Hi Bernt,
Bernt Hansen wrote:
> Sébastien Vauban <wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org>
> writes:
>> 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)))
>
> <snip>
>
>> 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*?
>
> If narrowing the buffer allows the state change when the parent (outside the
> narrowed region) has the ORDERED property - I think that's a bug that needs
> to be fixed.
Yes, it does. That has been my workaround once -- before searching more to
find the root cause.
> The behaviour shouldn't change if you narrow the buffer.
We share the same point of view.
Best regards,
Seb
--
Sébastien Vauban
