From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?S=C3=A9bastien_Vauban?= <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
Subject: Re: Re: TODO state change from TODO to DONE blocked
Date: Fri, 04 Mar 2011 22:52:53 +0100
Message-ID: <80ei6mmu2y.fsf@somewhere.org>
References: <80lj15yab6.fsf@somewhere.org> <80wrkp4dwo.fsf@somewhere.org>
	<87pqqeafov.fsf@gnu.org> <80hbbjq690.fsf@somewhere.org>
	<87hbbiuane.fsf@norang.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request-mXXj517/zsQ@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode-mXXj517/zsQ@public.gmane.org>
List-Help: <mailto:emacs-orgmode-request-mXXj517/zsQ@public.gmane.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request-mXXj517/zsQ@public.gmane.org?subject=subscribe>
Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org

Hi Bernt,

Bernt Hansen wrote:
> S=C3=A9bastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-XMD5yJDbdMSQIYZ4X/+iSw@public.gmane.org=
rg> writes:
>> Bastien wrote:
>>>>> I've a really weird exception occurring: change state from TODO to DO=
NE 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 cha=
nge if
>> tasks were ordered and a previous one not done. But I never use the orde=
red
>> 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 reaso=
n 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 inh=
erited
>>   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 nee=
ds
> 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

--=20
S=C3=A9bastien Vauban