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