Re: [O] Re: TODO state change from TODO to DONE blocked
Hi Bernt, Bernt Hansen be...@norang.ca writes: 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. Should be fixed now, thanks. -- Bastien
Re: [O] Re: TODO state change from TODO to DONE blocked
Awesome! Thanks! -Bernt Bastien b...@altern.org writes: Hi Bernt, Bernt Hansen be...@norang.ca writes: 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. Should be fixed now, thanks.
[O] Re: TODO state change from TODO to DONE blocked
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
Re: [O] Re: TODO state change from TODO to DONE blocked
Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: 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))) 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. The behaviour shouldn't change if you narrow the buffer. -Bernt
Re: [O] Re: TODO state change from TODO to DONE blocked
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
