[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /

From: Nicolas Goaziou
Subject: Re: [O] Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)]
Date: Mon, 24 Aug 2015 01:10:51 +0200

Completing myself:

> You are right, but I'm pretty sure the previous implementation of the
> property API didn't implement it this way, i.e., PRIORITY was not
> implemented like CATEGORY, at all. My gut feeling is that PRIORITY
> inheritance happened by side-effect.
> In any case, I see no objection to treat PRIORITY much like CATEGORY.

After some investigations, it appears that priority handling prior to
the changes (I tested in Org 7.9.4) was very confusing.

It appears "PRIORITY" could be inherited but not up to
`org-default-priority'. In the following example

  * [#A] Top
  ** Test 1
  * Top
  ** Test 2

evaluating (org-entry-get (point) "PRIORITY" t) on second line returned
"A", but nil on "Test 2". I would have expected "B" (i.e.,
`org-default-priority', as a string).

However, (org-entry-get (point) "PRIORITY") is never used throughout the
code base. Instead, Org relies on alternates solutions.

For example, `org-sort-entries' uses the following snippet, for priority

  ((= dcst ?p)
   (if (re-search-forward org-priority-regexp (point-at-eol) t)
       (string-to-char (match-string 2))

which also completely ignores inheritance. Sometimes, a dedicated
function, `org-get-priority', is used:

  (defun org-get-priority (s)
    "Find priority cookie and return priority."
      (if (functionp org-get-priority-function)
        (funcall org-get-priority-function)
        (if (not (string-match org-priority-regexp s))
          (* 1000 (- org-lowest-priority org-default-priority))
        (* 1000 (- org-lowest-priority
             (string-to-char (match-string 2 s))))))))

Here again, an entry without any priority cookie is treated as default
priority. Note that this function is usually called with the headline
itself as the argument, even without a priority cookie, not a parent
headline containing one.

`org-get-priority-function', although broken due to a missing argument,
gives another hint. Here is its docstring:

  Function to extract the priority from a string.
  The string is normally the headline.  If this is nil Org computes the
  priority from the priority cookie like [#A] in the headline.  It returns
  an integer, increasing by 1000 for each priority level.
  The user can set a different function here, which should take a string
  as an argument and return the numeric priority.

This one also couldn't care less about inheritance.

All in all, I'm not convinced "PRIORITY" inheritance was an intended
feature. At least the current change brings consistency to priority
handling: now there is no inheritance anywhere.

Another option is to make everything use inheritance. However,
`org-get-priority' and `org-get-priority-function' need to be sorted out
(e.g., what string should be passed?). It may be not as easy as it

reply via email to

[Prev in Thread] Current Thread [Next in Thread]