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: Wed, 19 Aug 2015 14:13:39 +0200	[thread overview]
Message-ID: <87y4h78oi4.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <871tez5xmo.fsf@gnu.org> (Bastien's message of "Wed, 19 Aug 2015 13:24:47 +0200")

Bastien <bzg@gnu.org> writes:

> After a few tests, I'm confused and I don't understand all the changes
> in this area (and they are not documented in ORG-NEWS.)

I'd rather clarify something here.

Most changes introduced come from bug reports, i.e., they are not a will
to change how things work in Org. Fixed bugs are not documented in
ORG-NEWS.

Unfortunately, once the fix is applied, it is hard to know if it
actually modifies some behaviour because the documentation doesn't, and
cannot, explain all the details and there are no tests to get a clue
about the original intent. For core functions, the bug fix usually
includes specifications tests to avoid encountering the same issue
again.

This is exactly what happened with "COMMENT" headlines. This is almost
the same for property API (the current change): I wanted to improve it
but had to switch from an ad-hoc model to a structured one.

To sum it up, this is not carelessness in filling up ORG-NEWS (though
omissions do happens occasionally) but fuzziness in how features are
described.

> Let's forget about what "special" means and how properties are
> displayed and set in the buffer.

On the contrary, it is important to understand that a few properties do
not follow the regular model and need to be handled specifically.

However, me way extend what "special" means. At the moment it only
includes properties not set through a property drawer. We could include
properties with a hard-coded inheritance patters (i.e., CATEGORY and
PRIORITY).

> We have four categories of properties:
>
> 1. those which are *never* inherited (like ITEM)
> 2. those which are *always* inherited (like CATEGORY)
> 3. those which inheritance relies on `org-use-property-inheritance'
> 4. those which are not part of the previous types
>
> (4) sounds a bit borgesian, but it's important: my understanding is
> that this fourth category *should* be empty.

I agree.

> Apparently it is not empty, since the PRIORITY property inheritance is
> not controlled by `org-use-property-inheritance'. Are there other
> exceptions?

I cannot think of any.

> There is a default priority the same way there is a default category:
> having a default value for the PRIORITY property should not prevent
> inheriting it from a superior headline IMO, and the previous behavior
> was right.

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.


Regards,

  reply	other threads:[~2015-08-19 12:12 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 [this message]
2015-08-23 23:10             ` Nicolas Goaziou

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=87y4h78oi4.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).