Thanks Jack for the helpful response and support of my assessment. I do intend to fix this as part of my ongoing (but currently delayed) work on improving agenda sorting and adding an option to manually sort.
On Tue, 9 Mar 2021 at 07:07, Jack Kamm <jackk...@gmail.com> wrote: > > Hi Adam, > > > I further noticed that this overloading of the internal priority by > > including timestamp and habit data causes disruption to the behaviour > > I imagine most users would expect from `org-agenda-sorting-strategy'. > > For example, if you have `priority-down' as the first entry in the > > `agenda' section and `category-keep' as the second, then differences > > in the SCHEDULED timestamp are included in the priority calculation > > and can therefore prevent sorting of two adjacent [#B] items by > > category. This seems like a bug to me, or at least breaks the > > Principle of Least Surprise. > > I just ran into this issue you highlight here. > > In particular, I was trying to set the org-agenda-sorting-strategy to > > (priority-down scheduled-down) > > i.e., sorting by priority (highest first), and then within priority, > sorting by scheduled (most recent first). > > However, the fact that the priority includes the scheduled timestamp > makes this sorting strategy impossible. > > I agree this seems like a bug, in that it contradicts the written > documentation as far as I can tell (for example, the *Help* for > org-agenda-sorting-strategy mentions nothing of the fact that the > priority includes the scheduled timestamp, and I don't see anything > about it in the *Info* either). > > I imagine that many have gotten used to the default behavior of sort by > highest priority, then by earliest scheduled timestamp, but we could > keep this default behavior by adding "scheduled-up" after > "priority-down" in org-agenda-sorting-strategy, as you allude. > > Jack
