Re: Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)]

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

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,