From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernt Hansen Subject: Re: Re: TODO state change from TODO to DONE blocked Date: Fri, 04 Mar 2011 11:13:09 -0500 Message-ID: <87hbbiuane.fsf@norang.ca> References: <80lj15yab6.fsf@somewhere.org> <80wrkp4dwo.fsf@somewhere.org> <87pqqeafov.fsf@gnu.org> <80hbbjq690.fsf@somewhere.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=41105 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PvXd6-00073C-Fw for emacs-orgmode@gnu.org; Fri, 04 Mar 2011 11:13:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PvXd4-0006GC-MN for emacs-orgmode@gnu.org; Fri, 04 Mar 2011 11:13:24 -0500 Received: from plane.gmane.org ([80.91.229.3]:36568) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PvXd4-0006Fl-Gu for emacs-orgmode@gnu.org; Fri, 04 Mar 2011 11:13:22 -0500 Received: from public by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1PvXd2-0005QL-6F for emacs-orgmode@gnu.org; Fri, 04 Mar 2011 17:13:20 +0100 In-Reply-To: <80hbbjq690.fsf@somewhere.org> (=?utf-8?Q?=22S=C3=A9bastien?= Vauban"'s message of "Fri, 04 Mar 2011 16:01:47 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: =?utf-8?Q?S=C3=A9bastien?= Vauban Cc: public-emacs-orgmode-mXXj517/zsQ@plane.gmane.org, Bastien S=C3=A9bastien Vauban writes: > Hi Bastien, > > Bastien wrote: >>>> I've a really weird exception occurring: change state from TODO to DON= E 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))) > I could see in the description of that var that it could block state chan= ge if > tasks were ordered and a previous one not done. But I never use the order= ed > 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 inhe= rited > 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