alphapapa
Priorities other than A,B,C
I use priorities below C constantly and for everything, and have just spent way too long being confused about whether I'm using org-ql wrongly, before finally finding a temporary workaround. It'd be really nice to update, or if nothing else change the docs to state that it ignores most values.
Quote from the source:
(;; NOTE: This only accepts A, B, or C. I haven't seen
;; other priorities in the wild, so this will do for now.
To expand on https://github.com/alphapapa/org-ql/pull/313#issuecomment-1326597605 a bit, ideally a general solution to this issue would use org-get-priority, which takes a string (typically a heading, I think) and returns an integer, and the sorting would use the resulting integers. org-get-priority will use org-priority-get-priority-function if the user has customized it, so it is guaranteed to work with whatever wacky priority systems are out there in Emacs configs :)
To expand on #313 (comment) a bit, ideally a general solution to this issue would use
org-get-priority, which takes a string (typically a heading, I think) and returns an integer, and the sorting would use the resulting integers.org-get-prioritywill useorg-priority-get-priority-functionif the user has customized it, so it is guaranteed to work with whatever wacky priority systems are out there in Emacs configs :)
That would work for the predicate body, but it might preclude regexp-based optimizations. It would need to be studied carefully to avoid performance regressions.
That parent-priority function in that SE answer wouldn't be necessary in org-ql, because we have the ancestor/parent selectors, so, e.g. (parent (priority)).
That would work for the predicate body, but it might preclude regexp-based optimizations. It would need to be studied carefully to avoid performance regressions.
Makes sense!
That parent-priority function in that SE answer wouldn't be necessary in org-ql, because we have the ancestor/parent selectors, so, e.g. (parent (priority)).
To be clear, I only included that link as one example of a custom priority function, which can be arbitrary. So even if Org QL has optimizations that improve upon that particular function, ultimately it can’t account for arbitrary priority functions without simply calling the function, I think?
To be clear, I only included that link as one example of a custom priority function, which can be arbitrary. So even if Org QL has optimizations that improve upon that particular function, ultimately it can’t account for arbitrary priority functions without simply calling the function, I think?
That's right. In the case of custom priority functions, hopefully the regexp-based optimizations can be used to find potential matches and then call the function to get the computed value, like several other predicates do anyway.