-
-
Notifications
You must be signed in to change notification settings - Fork 159
Configure group based sorting in agenda #128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Currently this logic is used: https://orgmode.org/manual/Sorting-of-agenda-items.html But it seems this should be configurable with this: https://orgmode.org/worg/doc.html#org-agenda-sorting-strategy. It seems that there is no a specific setting to sort by the todo keyword. Both TODO and NEXT keywords are basically a TODO state, and orgmode allows sorting by TODO -> DONE or vice versa. |
Ok so it says:
In orgmode.nvim the specific time todos are listed after the todos without a time of day, this is less useful, i.e. the emacs way sounds better. And the items are not grouped in categories in my case, even if I pass an explicit list of files rather than `org/*' they don't get sorted - I get the same mix as before. 👍 for sorting them by todo state too even if not emacs style 😉 |
Something like this (code here and from an article here) would be something that users would have to add manually, right? Based on the linked code, it appears that This looks like it would be something like this, which would accommodate for not just this use-case but realistically any "custom agenda view" use case. Not 100% sure of the state right now, but would something like this require changes to the core code (this repo.) @kristijanhusak? |
@levouh If we would add some similar configuration, then yeah, it would require some changes, and probably not so small ones. I'm not even sure what's possible with the custom agenda command, I would have to investigate. There is like an AgendaItem that basically wraps all logic around determining what and where to show, so that can be reused, but rendering itself would need changes. |
Makes sense, I'll see if I can't come up with a good summary before taking a stab at what the code might actually look like. Can open up a separate issue to track it as well, whichever you'd prefer. The main start on the issue would be:
|
Awesome, thanks! That will help tremendously. You can open up a separate enhancement issue, since this is related only to sorting. |
@gerazov can you double check how Emacs orgmode is doing the sorting? I think I adjusted it to work the same way as there, but maybe I missed something. |
Yeah it's like that in the specs as far as I can tell (and it feels right too 😅 )
Plus the randomization is minimized to within category listings, which is a bit weird since they are read from the same file 🤔 I haven't added the priorities though for the no time-of-day entries, will do that and update. I'm not sure about the
It reads to me that first comes the overdue deadline, then the overdue scheduled item, then the priority items, then the regular items, no? I can also implement this for the todo-s list. |
Ok, it's now taking deadlines into account, but deadlines are sorted before overdue scheduled items. I'm not sure how it is in emacs as the spec doesn't read very exact. Here's what I get for 3 deadlines (1 overdue, 1 today, 1 tomorrow), 1 overdue scheduled item and 1 today item: I'm happy with this, how does it look to you guys? |
If you want I'll look into this during this week, you just need to be a bit patient :) |
Yes please 😅 no hurry 😉 |
Will do. Once I'm done with the |
@gerazov I pushed a change that should make agenda sorting exactly the same as Emacs in orgmode, at least it was same in my tests. |
Ok awesome 😎 I'll give it a go! |
@gerazov did you do |
Tried that now - still same problem. It's fine if I use my fork, so I guess it isn't neovim doing funny business. |
@gerazov Try doing |
Yup works! 🙏 The sorting is not ok though - the tasks that do not have a time of day stamp should be sorted by category first:
|
I would suggest to set up basic emacs installation and compare with that. I did 1 to 1 comparison while setting up the sorting. Maybe what is written and what really happens is not exactly the same. |
That doesn't seem right. Did you try with multiple categories? Now the overdue items get sorted before today's items, which let's say is ok, but not ideal (and not following specs). Still, even with all the scheduled items for today I get a mix of categories. This is surely not useful (i.e. I can't imagine what are they prioritized with?) And things really gets messy once you have 10+ org files and the tasks from different categories get mixed. Here's a glimpse (these are all tasks scheduled for today 😅): I implemented category based sorting in my fork and it works well: -- if different categories sort by category
if a.headline:get_category() ~= b.headline:get_category() then
return category_inds[a.headline:get_category()] < category_inds[b.headline:get_category()]
end |
Is this a screenshot from Neovim or emacs Orgmode? |
Yeah I can go with the overdue priority sorting, but the sorting for tasks scheduled for the same day (with no/equal priorities) should be category based no? The screenshot is with neovim. |
I think it just uses the default sorting, which is as things appear in the files. |
I've given it another go - rebasing and squashing. I can't figure out how to apply the category sorting to the same date items only 😅 The default sorting is actually the problem because the files are read asynchronously - this mixes them up. But, I would keep the async loading mosdef 👍 |
Ok installing emacs and configuring orgmode seems quite involved - that's how I came here in the first place 😅 What I've done is create a minimum working example. Here are three identical files having 4 tasks scheduled for today. I had to rename them to * TODO Task 1
SCHEDULED: <2021-12-17 пет>
* TODO Task 2
SCHEDULED: <2021-12-17 пет>
* TODO Task 3
SCHEDULED: <2021-12-17 пет>
* TODO Task 4
SCHEDULED: <2021-12-17 пет> Now when I run the agenda it shows: I don't know if emacs reproduces this, but this mixing of categories and tasks within categories doesn't make sense. In fact, it's counter productive. Also based on this MWE I'm not sure if it's the async loading doing it anymore - it seems random (yet refreshing it doesn't change the ordering) 🤔 |
I've made the category based sorting in the PR, but it follows the spec, i.e. sorts by category and then by overdueness. (within category I still get the weird mix but this doesn't bother me as the position of the task in the file is not that important). I've tried making it work overdue > category but can't make it work ... The expanded files have three more old tasks: * TODO Task 1
SCHEDULED: <2021-12-17 пет>
* TODO Task 2
SCHEDULED: <2021-12-17 пет>
* TODO Task 3
SCHEDULED: <2021-12-17 пет>
* TODO Task 4
SCHEDULED: <2021-12-17 пет>
* TODO Task 5
SCHEDULED: <2021-12-16 чет>
* TODO Task 6
SCHEDULED: <2021-12-15 сре>
* TODO Task 7
SCHEDULED: <2021-12-14 вто> |
Ok with 7ba698a it now works based on overdues + categories: |
I've also added deadlines in the mix. At first it's mixing them with the regular items: But with f6678a4 it's ok 🤟 |
@gerazov I tested your files with emacs orgmode, and you were right, it sorts by category in these cases. I pushed a fix where sorting falls back to the default order of headlines being loaded. Pull latest master and give it a test. |
@gerazov is there anything left to this issue or can I close it? |
I guess so 😅 closing ... |
Does this feature exist in Emacs orgmode core?
N/A
Orgmode link
No response
Feature value
The sorting of tasks in the agenda view seems a bit arbitrary - I get a mix of NEXT and TODO items, and the files they come from are also mixed even if all the tasks are for the same date. I couldn't find how sorting is done in the help file...
For e.g. I get:
It would be very helpful if there is a way to group items based on keywords and files, and possibly set different priorities for sorting them in the agenda, e.g.
DONE > DOING > NEXT > TODO
👍Additional context
No response
The text was updated successfully, but these errors were encountered: