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/)]

[Michael Dickens]

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/)