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: Wed, 19 Aug 2015 14:13:39 +0200 Message-ID: <87y4h78oi4.fsf@nicolasgoaziou.fr> References: <87wpwrab3l.fsf@nicolasgoaziou.fr> <87fv3fmvmz.fsf@gnu.org> <87fv3fa7rh.fsf@nicolasgoaziou.fr> <8737zfa6hm.fsf@nicolasgoaziou.fr> <871tez5xmo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS2Dw-0002XA-Dv for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 08:12:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS2Dv-0000DC-FI for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 08:12:08 -0400 In-Reply-To: <871tez5xmo.fsf@gnu.org> (Bastien's message of "Wed, 19 Aug 2015 13:24:47 +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 Bastien 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,