* Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)]
@ 2015-08-18 13:47 Luke Amdor
2015-08-19 9:20 ` Nicolas Goaziou
0 siblings, 1 reply; 8+ messages in thread
From: Luke Amdor @ 2015-08-18 13:47 UTC (permalink / raw)
To: org-mode Mode
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
Given a test.org with:
* [#B] Test
** TODO one
When I do the agenda to find TODO headlines with priority B I would expect
it to find the "TODO one", however it doesn't. I'm very sure this regressed
when upgrading to 8.3.1, as it worked fine in 8.3.0. Thanks!
Emacs : GNU Emacs 24.5.1 (x86_64-apple-darwin14.1.0, NS
apple-appkit-1344.72)
of 2015-04-17 on MacBook-Pro.local
Package: Org-mode version 8.3.1 (8.3.1-56-g17a225-elpa @
/Users/luke/.emacs.d/elpa/org-20150817/)
(add-to-list 'load-path (expand-file-name "./org-mode/lisp"))
(add-to-list 'load-path (expand-file-name "./org-mode/contrib/lisp" t))
(setq inhibit-startup-message t)
(setq org-use-property-inheritance t)
(setq org-agenda-files (list "test.org"))
(setq org-agenda-custom-commands
'(("t" "Test" ((tags-todo "+PRIORITY=\"B\"")))))
Luke
[-- Attachment #2: Type: text/html, Size: 1389 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)] 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 0 siblings, 1 reply; 8+ messages in thread From: Nicolas Goaziou @ 2015-08-19 9:20 UTC (permalink / raw) To: Luke Amdor; +Cc: org-mode Mode Hello, Luke Amdor <luke.amdor@gmail.com> writes: > Given a test.org with: > > * [#B] Test > ** TODO one > > > When I do the agenda to find TODO headlines with priority B I would expect > it to find the "TODO one", however it doesn't. I'm very sure this regressed > when upgrading to 8.3.1, as it worked fine in 8.3.0. Thanks! There is a misunderstanding here. Special properties, like PRIORITY, cannot be inherited. However, in this case, "one" has a default priority, defined in `org-default-priority'. Since it is usually B, it should appear nonetheless in your sparse tree. It is fixed. Thank you. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)] 2015-08-19 9:20 ` Nicolas Goaziou @ 2015-08-19 10:15 ` Bastien 2015-08-19 10:32 ` Nicolas Goaziou 0 siblings, 1 reply; 8+ messages in thread From: Bastien @ 2015-08-19 10:15 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: org-mode Mode, Luke Amdor Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > There is a misunderstanding here. Special properties, like PRIORITY, > cannot be inherited. The PRIORITY property *was* inherited. At least in 8.2.10. It is reasonable to expect the PRIORITY property to be inherited and the new behavior (falling back on the default priority) is confusing. I see a lot of work on the way Org get properties since one year. How hard would it be to restore the previous behavior? Are there any other changes that we need to know from a user point of view? Thanks, -- Bastien ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)] 2015-08-19 10:15 ` Bastien @ 2015-08-19 10:32 ` Nicolas Goaziou 2015-08-19 10:59 ` Nicolas Goaziou 0 siblings, 1 reply; 8+ messages in thread From: Nicolas Goaziou @ 2015-08-19 10:32 UTC (permalink / raw) To: Bastien; +Cc: org-mode Mode, Luke Amdor Bastien <bzg@gnu.org> writes: > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > >> There is a misunderstanding here. Special properties, like PRIORITY, >> cannot be inherited. > > The PRIORITY property *was* inherited. At least in 8.2.10. 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. 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. Regards, ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)] 2015-08-19 10:32 ` Nicolas Goaziou @ 2015-08-19 10:59 ` Nicolas Goaziou 2015-08-19 11:24 ` Bastien 0 siblings, 1 reply; 8+ messages in thread From: Nicolas Goaziou @ 2015-08-19 10:59 UTC (permalink / raw) To: Bastien; +Cc: org-mode Mode, Luke Amdor 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)] 2015-08-19 10:59 ` Nicolas Goaziou @ 2015-08-19 11:24 ` Bastien 2015-08-19 12:13 ` Nicolas Goaziou 0 siblings, 1 reply; 8+ messages in thread From: Bastien @ 2015-08-19 11:24 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: org-mode Mode, Luke Amdor Nicolas Goaziou <mail@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)] 2015-08-19 11:24 ` Bastien @ 2015-08-19 12:13 ` Nicolas Goaziou 2015-08-23 23:10 ` Nicolas Goaziou 0 siblings, 1 reply; 8+ messages in thread From: Nicolas Goaziou @ 2015-08-19 12:13 UTC (permalink / raw) To: Bastien; +Cc: org-mode Mode, Luke Amdor 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, ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)] 2015-08-19 12:13 ` Nicolas Goaziou @ 2015-08-23 23:10 ` Nicolas Goaziou 0 siblings, 0 replies; 8+ messages in thread From: Nicolas Goaziou @ 2015-08-23 23:10 UTC (permalink / raw) To: Bastien; +Cc: org-mode Mode, Luke Amdor 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-08-23 23:09 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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
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).