From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: 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 Message-ID: <87vbc5wqh0.fsf@nicolasgoaziou.fr> References: <87wpwrab3l.fsf@nicolasgoaziou.fr> <87fv3fmvmz.fsf@gnu.org> <87fv3fa7rh.fsf@nicolasgoaziou.fr> <8737zfa6hm.fsf@nicolasgoaziou.fr> <871tez5xmo.fsf@gnu.org> <87y4h78oi4.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTeO9-0007ei-Jk for emacs-orgmode@gnu.org; Sun, 23 Aug 2015 19:09:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTeO8-0002lm-KM for emacs-orgmode@gnu.org; Sun, 23 Aug 2015 19:09:21 -0400 In-Reply-To: <87y4h78oi4.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Wed, 19 Aug 2015 14:13:39 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: org-mode Mode , Luke Amdor 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 sorting: ((= dcst ?p) (if (re-search-forward org-priority-regexp (point-at-eol) t) (string-to-char (match-string 2)) org-default-priority)) 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." (save-match-data (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 seems.