Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Correcting myself, > >> AFAIK, PRIORITY never was intended to be inherited. Inheritance applies >> to node properties, i.e. property drawers, whereas special properties, >> like PRIORITY are, by definition, not set through property drawers. > > This is incorrect. What I mean is inheritance is not automatic for > special properties, unlike to regular node properties. > > In any case, this doesn't depend on `org-use-property-inheritance'. Few > of the special properties are inherited, e.g., BLOCKED, and /always/ > are, most are never inherited, e.g. ITEM. > >> There is also a technical issue: Org defines a default priority, so >> PRIORITY is never empty. Again, inheritance kicks in when a property is >> undefined at some level. This never happens in this case. > > We need to redefine `org-default-prority' to solve this, e.g., the > variable only applies to top-level items.
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.) Let's forget about what "special" means and how properties are displayed and set in the buffer. 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. Apparently it is not empty, since the PRIORITY property inheritance is not controlled by `org-use-property-inheritance'. Are there other exceptions? 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. I know dwelling on this is boring but we need to do so, at least to clarify changes in etc/ORG-NEWS. Thanks, -- Bastien
