(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.
