emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Bastien <bzg@gnu.org>
Cc: org-mode Mode <emacs-orgmode@gnu.org>, Luke Amdor <luke.amdor@gmail.com>
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	[thread overview]
Message-ID: <87vbc5wqh0.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87y4h78oi4.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Wed, 19 Aug 2015 14:13:39 +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
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.

      reply	other threads:[~2015-08-23 23:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18 13:47 Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)] Luke Amdor
2015-08-19  9:20 ` Nicolas Goaziou
2015-08-19 10:15   ` Bastien
2015-08-19 10:32     ` Nicolas Goaziou
2015-08-19 10:59       ` Nicolas Goaziou
2015-08-19 11:24         ` Bastien
2015-08-19 12:13           ` Nicolas Goaziou
2015-08-23 23:10             ` Nicolas Goaziou [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vbc5wqh0.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=luke.amdor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).