[BUG] Numeric priorities only partially supported

[BUG] Numeric priorities only partially supported

[Tommy Jollyboat]

(tested with Org 9.7.11, I've done my best to search archives and the
bug-tracker)

Back in 2020, commit #4f98694bf introduced numeric priorities,
allowing [#1] to [#64] as an alternative to [#A] to [#Z]. This is also
documented in the manual.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4f98694bf
https://orgmode.org/manual/Priorities.html

It introduced the new function ~org-priority-to-value~, which replaces
~string-to-char~ for parsing priority strings. It parses numeric prios
as ints (1..64) and alphabetic prios as chars (?A..?Z, which is
65-90).

* PROBLEM

However, various functions within org-mode are still using
~string-to-char~ and giving inconsistent results, because numerical
priorities are parsed wrongly, or sometimes return nil (or #10 to
#64).

* EXAMPLES

With the following heading tree:

* test tree
** [#10] ten
** [#2] two

You can get the correct values 10 and 2 with: (org-priority-to-value
(thing-at-point 'line))

You can get incorrect values nil and ?2 with: (org-element-property
:priority (org-element-at-point)) or (nth 3 (org-heading-components))

And if you sort the test tree by priority (with org-sort-entries,
"p"), it won't change, because [#10] is wrongly interpreted as if it
were [#1].

* SOLUTION

If we agree that numeric priorities should be supported everywhere,
various functions need updating:

Functions that use string-to-char to parse:
- org-entry-put
- org-mobile-edit (in org-mobile.el)
- org-agenda-fontify-priorities (org-agenda.el)
- org-mouse-context-menu (org-mouse.el)

I've confirmed that org-entry-put exhibits wrong behaviour (parsing
1-9 as ?1-?9 and 10-64 as nil). I'm not familiar with the others, as
they're in modules I don't use.

The Org Element API also needs updating:
- ~org-element--headline-parse-title~ implements its own
org-priority-regexp, which doesn't account for multiple characters
- ~org-entry-put~ has bugs, but I don't understand the code well enough
- A couple of functions format priorities as "[#%c]", and should
include a %s case for values under 65.

These should all be fairly safe/uncontroversial changes to make, as
any documents that are impacted were relying on undefined behavior
(such as using chars outside of the range A-Z as priorities).

Hope that's all clear! Sorry it's a bit of an essay.

Re: [BUG] Numeric priorities only partially supported

[Ihor Radchenko]

Tommy Jollyboat <jollyboatbros@gmail.com> writes:

> However, various functions within org-mode are still using
> ~string-to-char~ and giving inconsistent results, because numerical
> priorities are parsed wrongly, or sometimes return nil (or #10 to
> #64).

Confirmed.

> * SOLUTION
>
> If we agree that numeric priorities should be supported everywhere,
> various functions need updating:
> ...

Yes.

> These should all be fairly safe/uncontroversial changes to make, as
> any documents that are impacted were relying on undefined behavior
> (such as using chars outside of the range A-Z as priorities).

Not so safe. I tried to fix this specific issue in the past and changing
the org-element parser to handle non-single char priorities broke
tests (either because I did something stupid or because the tests make
incorrect assumptions).

It would be really nice if someone worked on this issue and resolved all
the possible corner cases in the tests and elsewhere.

We must eventually support numeric properties, as documented in the manual.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>