(Agenda Bug) State change on REPEATING TODO's doesn't work

[stoladev]

Describe the bug

When a TODO item is set to a SCHEDULED REPEAT (ex. +1d | +1w), it does not visually update into a done state nor remove itself from that day's view.

WORKS if you re-open agenda view. Seems to be a visual-update type of bug.

Steps to reproduce

1. Create a REPEATING TODO item.
2. Open agenda view.
3. Change the status of it.

Expected behavior

WHAT WORKS:

• The TODO item successfully adds a property to itself (state DONE from TODO)
• When you reload agenda view, that item is no longer visible for the day you set it done for
• The other items still successfully display for other days

WHAT DOESN'T WORK:

• The reason I noticed this issue was because after I hotkeyed the daily task for being DONE
• It didn't update the visual of TODO -> DONE
• Another thing it could have done was remove itself from my view, which it didn't either
• Only AFTER I re-open agenda view, is the item gone for the day I finished it from.

WHAT I THINK THE PROBLEM IS:

• I think adding some form of visual refresh after changing a TODO item's state would be enough to fix this issue.

POTENTIAL FIX:

• Either visually changing the item to DONE (the same way it works in Agenda Mode with a NON-REPEATING TODO)
• ...or removing that day's TODO item from the view

Emacs functionality

No response

Minimal init.lua

Minimal init.lua:
https://github.com/nvim-orgmode/orgmode/blob/master/scripts/minimal_init.lua

Screenshots and recordings

No response

OS / Distro

MacOS

Neovim version/commit

0.8

Additional context

No response

[gerazov]

I've noticed this as well. You can also r to refresh the Agenda and the done repeat disappears.

It's nice to have it stay 🙂

[kristijanhusak]

Actually "staying" is a feature, because it allows to to undo changes in case you want. That's how Emacs work.

Edit: As @gerazov said, you can just press r to redraw the agenda.

[gerazov]

Yeah it also helps with figuring out what you did that day 😅

[stoladev]

Understood. Thanks, gentlemen.

[gerazov]

Why close? The bug is still there 🤔

[stoladev]

Why close? The bug is still there 🤔

I misunderstood you guys saying that it's intended to work this way because it's a feature; apologies. Reopened.

Also, there are plenty of cases of items not removing themselves even after a refresh event. I will upload a clip to display the issue soon.

[kristijanhusak]

I misunderstood you guys saying that it's intended to work this way because it's a feature

It is a feature. Here's how emacs does it:

And how it's in Neovim:

Only difference is that Emacs shows the "Done" keyword, even though it's not "Done" in the org file.

Also, there are plenty of cases of items not removing themselves even after a refresh event

This should not be happening. Make sure to test with minimal_init.lua

[gerazov]

But it doesn't make sense to remove it from the Agenda if it's done. It still should be there so you can see what you did that day/time like with any other task no?

[jgollenz]

even though it's not "Done" in the org file

Not sure I understand that correctly. So even though, the item is set to DONE it is actually not DONE in the org file yet? When does it persist? Upon opening another buffer?

[stoladev]

This issue pertains to repeating tasks, meaning that if you complete a daily task (for example "brush teeth"), you want to complete it for today but still leave it in your agenda for all the following days.

Setting the DONE property with timings is what happens currently, and on agenda refresh, it properly disappears from today's agenda view while remaining for all the following ones.

The issue at hand is it doesn't do this automatically as shown in the Emacs comparison. You must refresh to see it gone.

[stoladev]

But it doesn't make sense to remove it from the Agenda if it's done. It still should be there so you can see what you did that day/time like with any other task no?

I am a meticulous person, as I am sure many of you are (we're using individually customized consoles to practically run our entire lives).

Because of this, I create numerous events (with cronjobs/ OS reminders to keep me in check with my scheduled tasks, meetings, etc.)

Without filtration, my daily agenda view shows upwards of 50+ items per day (most are repeating).

After completion, finishing a task for the day (no matter what it is) should remove itself from that day's Agenda.

Sure, I think it showing a green "DONE" status after you mark it done for that day is fine, but removing it on agenda refresh is so that you don't clutter your view with "DONE" tasks throughout.

To play devil's advocate, a different approach would be to create a separate system for "dailies" (as I like to call them) where they act differently than other tasks. I understand the mental benefit and positive reinforcement of seeing "DONE" items on your Agenda whenever you look at it. If only there were a way to separate these two types of agenda-view tasks...

What are everyone's thoughts on tackling this issue? Bandage the problem with a plugin, or add this functionality to main? I could potentially create the plugin given some special APIs to the agenda view and its functionality.

[jgollenz]

@stoladev I would love to see that functionality in nvim-orgmode as well. It looks like vanilla orgmode already has something similar that could be used for your use case. Not sure about the orgmode terminology here. They call it a 'module', but it is not in the contrib repository like e.g. orgmode-contacts. Seems to be core orgmode 🤷‍♂️ which in turn means, it should be part of this repository actually

[stoladev]

@jgollenz As this is my first time truly using orgmode (thanks to this amazing port), it's also the first time I've seen the specifics you've provided. That's exactly what I would categorize them as - habits.

The question now is do we:

1. Integrate this to base
   Or
2. Make it a plugin
   Or
3. Begin a framework similar to how eMacs's orgmode uses these plug-and-play modules.

#3 would require much more time but it would open the floodgates to other orgmode modules available on eMacs. Development would be as easy as porting the code over (granted that the initialization/enabling of addons process is mostly similar).

I suggest a framework where instead of packing all nvim-orgmode plugins in (ex) Packer, they can instead be handled (including installation/removal) through an orgmode_modules.lua file (or orgmode.modules.setup).

Rough ideas with much to polish, but I am willing to put in the effort for improving this fantastic port. It has done nothing other than improve my organization in all aspects. There is so much more to explore regarding the utilization cases of nvim-orgmode.

[jgollenz]

@stoladev we actually discussed org-habit before. I don't know how orgmode actually does things under the hood, but it looks like those modules are just single .el files that are shipped with orgmode (i.e. are in the orgmode package) and are then enabled on-demand. So your third point with a separate repository is not really how its done in vanilla orgmode (to my knowledge, which is very limited). That does not mean, that we could not do something like that.
Making it a plugin (point 2) is feasible, but again, does not exactly mirror how org-habit is handled in orgmode. What I called 'contrib repository' in my earlier post is really just this folder. I'd consider those to be plugins and stuff like org-habit as modules (to stick with the terminology on the orgmode website). So now we have three categories:

• modules (ship with orgmode)
• contrib plugins (don't ship, but are 'well known™')
• plugins (whatever floats around the interwebs)

Your proposed way would combine all those into one framework, just dividing it up into plugins that we provide and plugins that other people wrote (please correct me, if I misunderstood). It has the benefit of unifying what a plugin is, but it also means that all the stuff that is now modules, need their own repositories (== overhead). Additionally, we would need to build our own package manager within this repository. That is beyond the scope of what this port is about in my opinion (@kristijanhusak might disagree). Also, I know of no nvim plugin that did go down this route. nvim-cmp does have a multi-repo infrastructure, but those also are just pulled with packer.

This conversation is valuable and I think we should move to #26 from here on ;)

[gerazov]

Opening up the flood gates for plugins does sound promising 👍

@stoladev I see your point for not crowding the agenda with small tasks. I use repeater tasks for larger things - like 1h music classes twice a week. So if I go back in the Agenda view I'd like to see them there as any other tasks.

It seems that the habit styling @jgollenz suggested allows users to go both ways, i.e. have habits disappear (along with a consistency plot, which sounds cool 😎 ) and (possibly) have normal repeated tasks stay.

So do we close this issue and we open 2 new feature requests - one for having normal completed repeated tasks stick (even though emacs orgmode doesn't support it 😅 ), and one for porting habit?

[kristijanhusak]

I investigated habits a little bit. They have their own set of additional functionality (see screenshot https://i.imgur.com/VYDkoPY.png), but are very similar to the classic recurring task. When you complete a habit for today, it's gone from the agenda (Check 1st July in Emacs on screenshot), so functionality to always keep them visible seems to not be working also in Emacs orgmode. My guess is that it's possible to have them always visible only with the custom agenda commands (#135), but those are still not done.
Since this is not a bug, I'm closing it in favor of #359. Discussion can continue there if necessary.