From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Dickens Subject: Bug: Custom TODO fields not rendered when preceded by priority [9.1.14 (9.1.14-9-g131531-elpaplus @ /Users/michaeldickens/.emacs.d/elpa/org-plus-contrib-20181217/)] Date: Wed, 23 Oct 2019 10:29:08 -0700 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bbbd27059597414e" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58368) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNKRm-0001gO-4W for emacs-orgmode@gnu.org; Wed, 23 Oct 2019 13:29:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iNKRk-0008T4-LF for emacs-orgmode@gnu.org; Wed, 23 Oct 2019 13:29:21 -0400 Received: from mail-oi1-x235.google.com ([2607:f8b0:4864:20::235]:42572) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iNKRk-0008SR-Er for emacs-orgmode@gnu.org; Wed, 23 Oct 2019 13:29:20 -0400 Received: by mail-oi1-x235.google.com with SMTP id i185so18078033oif.9 for ; Wed, 23 Oct 2019 10:29:20 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org --000000000000bbbd27059597414e Content-Type: text/plain; charset="UTF-8" Hi, It seems that org-mode does not correctly parse custom to-do states when they are preceded by a priority. This example org-mode file demonstrates the issue: #+TODO: TODO BLOCKED DONE * TODO [#A] this works * BLOCKED [#A] this works * [#A] TODO this works * [#A] BLOCKED this does not work On the first three lines, Emacs correctly recognizes the to-do state and renders it as a different color, and commands to cycle the state work correctly. But on the fourth line, Emacs doesn't understand that 'BLOCKED' is supposed to be a to-do state, and if I cycle the state with C-c C-t, it adds the keyword to before the priority, like this: * TODO [#A] BLOCKED this does not work To make sure it wasn't an issue with my config, I asked an Emacs-using coworker to replicate, and his didn't work either, but it behaved incorrectly on both lines 3 and 4, whereas mine behaves correctly on line 3 but not on line 4. You could argue that this is expected behavior and the priority should go after the to-do state, but IMO it should work either way because it can still be unambiguously parsed. I have some Emacs extensions that automatically put the priority before the to-do state, which then causes Emacs to parse the header incorrectly. Thanks, Michael Emacs : GNU Emacs 26.1 (build 1, x86_64-apple-darwin18.2.0, Carbon Version 158 AppKit 1671.1) of 2018-12-13 Package: Org mode version 9.1.14 (9.1.14-9-g131531-elpaplus @ /Users/michaeldickens/.emacs.d/elpa/org-plus-contrib-20181217/) --000000000000bbbd27059597414e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

It seems that org-mode does not correctly parse custom to-do states when=
= they = are preceded by a priority. This example org-mode file demonstrates<= br style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:12px">the issue:
=C2=A0=C2=A0=C2=A0=C2=A0#+TODO: TODO BLOCKED DONE
=C2=A0=C2=A0=C2=A0=C2= =A0* TODO [#A] this works
=C2=A0=C2= =A0=C2=A0=C2=A0* BLOCK= ED [#A] this works
=C2=A0=C2=A0=C2=A0=C2=A0* [#A] TODO this works=
= =C2=A0=C2=A0=C2=A0=C2=A0* [#A] BLOCKED this does not work=

On the first three = lines, Emacs correctly recognizes the to-do state and
renders it as a different c= olor, and commands to cycle the state work
correctly. But on the fourth line, Ema= cs doesn't understand that
'BLOCKED' is supposed to be a to-do state,= and if I cycle the state with
C-c C-t, it adds the keyword to before the priorit= y, like this:

=C2=A0=C2=A0=C2=A0=C2=A0* TODO [#A] BLOCKED this does not = work

To make = sure it wasn't an issue with my config, I asked an Emacs-usingcoworker to re= plicate, and his didn't work either, but it behaved
incorrectly on both lines= 3 and 4, whereas mine behaves correctly on
line 3 but not on line 4.

You could argue that thi= s is expected behavior and the priority should
go after the to-do state, but IMO = it should work either way because it
can still be unambiguously parsed. I have so= me Emacs extensions that
automatically put the priority before the to-do state, w= hich then causes
Emacs to parse the header incorrectly.

Thanks,
Michael

Emacs=C2=A0=C2=A0: GNU = Emacs 26.1 (build 1, x86_64-apple-darwin18.2.0, Carbon Version 158 AppKit 1= 671.1)
of 2018-12-13
Package: Org mode version 9.1.14 (9.1.14-9-g131531-elpaplus @ /Use= rs/michaeldickens/.emacs.d/elpa/org-plus-contrib-20181217/)
--000000000000bbbd27059597414e--