nvim-orgmode
Tracking TODO state changes
Does this feature exist in Emacs orgmode core?
Yes
Orgmode link
https://orgmode.org/manual/Tracking-TODO-state-changes.html
Feature value
No response
Additional context
No response
I'm taking a crack at this. The development branch for it is here
Not sure when I'll finish it since I'll just be working on it as I have time.
Just wanted to update what state the branch is in. I had planned to work on the feature over my Christmas vacation but unfortunately I fell ill and didn't make much progress on it. I've started working on the feature again in my off hours and I'm currently dogfooding my changes.
In its current state, a :LOGGING: value of nil will successfully turn the logging off. I've written the logic for parsing the syntax of the :LOGGING: property, but I still need to validate it, and use the config for affecting the TODO state change behavior. Hopefully in another few days I'll have that done though.
@PhosCity are you familiar with how :LOGGING: affects the state change behavior in emacs? The only feature I really needed out of it currently is being able to disable logging for some of my repeating tasks. When I'm done will you be able to test it to confirm it behaves in the same way that emacs does?
Hi, thank you for working in this feature. Unfortunately I won't be of much help to you in this regard. I don't use emacs myself so I can only determine the behavior of emacs by reading docs which I'm sure you've done already. So I can't add anything further.
I hope someone else who uses emacs can help us here.
Hi, thanks a lot @chuck-flowers for taking a crack at this, it's an important feature in my opinion. I may be able to help with testing to confirm the behavior is the same as in emacs, I use the nvim-orgmode plugin most of the time but go to emacs for stuff not fully supported yet (like habits).
Besides being able to disable logging it would be great if we can optionally save state changes into the LOGBOOK drawer (or ideally user-selected drawer), which is especially important for habits that can have a lot of state changes that may clutter the view. Furthermore, it would be awesome if became possible to add configuration on a per-keyword basis as in emacs, please see the Org Manual for a description: 5.3.2 Tracking TODO state changes
I have a PR for another feature that includes some improved parsing logic I want to use for this PR. I'll likely rebase my work on that PR at some point to leverage that for parsing the TODO state change configuration syntax.
Hi!
First of all thanks @chuck-flowers for working on this feature. I was wondering what the current state for your other PR is that you want to rebase your work on? And if there is anything, I might be able to help with to get this feature into the main line? It be great to have it.
@schuam, My other PR was merged some time ago, I've been trying to find some time to resume develoment on this feature once again. I just reached a solid checkpoint in a personal project so I'll start working on developing this once more.
As far as assistance in writing the PR goes, I don't think there's a good way to split the work. You are more than welcome to work on your own implementation if you like. I don't think it will take me more than a few days to have some sort of prototype created.
Just an update for anyone tracking this issue. The change I was waiting to get merged was a parsing framework that I wrote for the agenda search syntax. I'm using this to parse the TODO(t) | DONE(d!) style configuration that I saw on the linked org mode documentation page.
I wrote the parser for this syntax last night so I believe I can have a prototype ready by some time next weekend. I started a fresh branch for writing the parser and when I have something usable I'll link the branch here so if anyone wants to update their plugin manager and play with my changes they can.
@chuck-flowers I guess I misinterpreted your previous comments. Somehow I thought you had the feature more or less implemented and just wanted to rebase it on another PR (and maybe make some adjustments). In such a case, I figured I could help by doing that, as this might not involve unterstanding the every detail of how the orgmode plugin works. It might have been a great opportunity to get into it though. Implementing my own version would of this feature, will take me a lot longer, as I have to dig into the code and understand how it works and where to modify it. Also an interesting chellange, but I don't know if I find enought time in the near future to do so.
@schuam sorry for the misunderstanding
Good news though! I think I have a version of the change published to my fork of orgmode. I'm going to use it myself for the rest of the week before I open a PR in case there are some issues I haven't detected yet, but I think it is usable and would love any feedback users can provide. You can find the relevant branch here
I think it's implemented correctly based of my understanding of the org mode manual, but if anyone finds a difference between my implementation and how Emacs works, please provide an example on this issue.
@chuck-flowers:
Since I have never used Emacs, I won't be able to compare your implementation with Orgmode in Emace. But I thought I'd try it out anyways and provide feedback on my experience. Unfortunately I wasn't able to make it run.
So far I have pointed packer to use your branch of the plugin and added "@" and "!" to my keywords:
ord_todo_keywords = { 'TODO(t!)', 'WAIT(w@)', '|', 'DONE(d@)' },
I also have the following two settings im my orgmode configuration:
org_log_done = 'time',
org_log_into_drawer = 'LOGBOOK',
Somehow I don't get any logging of state changes. I tried it with and without the org_log_into_drawer setting. Neither worked. Am I missing something obivous? Do I need anything else? If not, I will have to dig deeper to find out, what's going on.
@schuam, my change doesn't do anything with the org_todo_keywords configuration property. My focus was on the :LOGGING: property within the :PROPERTIES: drawer of a heading/section. I think it would be easy enough to add support in for the property you're describing but I would want to double check Emac's documentation to make sure I match the behavior.
EDIT
Just to add an example, your section should looking something like the following
* TODO My Task
:PROPERTIES:
:LOGGING: TODO(t!) WAIT(w@) | DONE(d@)
:END:
Hey @schuam, I just pushed a patch to the branch that will use the property you mentioned as well. I'm not sure if it's the same behavior as Emacs, but it should do what you want now
Hi @chuck-flowers, I didn't want to cause any more work, but I hihgly appreciate the change. Thanks a lot. Sadly it still does not work for me. Neither does adding the :LOGGING: property. So I guess I have some other issue. Unfortunately, I won't be able to try tracing down the issue in the next few days, but I hope to get to it soon (maybe on Sunday or early next week).
@schuam, it wasn't a lot of trouble on my part. It was the same syntax that is used in the :LOGGING: property so I was able to feed it to the same parser.
I'm sorry to hear you're still having trouble. When you have time to investigate again, I would confirm that Packer has actually used the branch from my repository. I remember when used to use Packer it was really easy to forget to run the 'compile' after changing a config and plugins not being updated or loading properly.
I would recommend going to directory where the repository is cloned and using the git CLI to verify what version of the plugin code you have there.
cd ~/.local/share/nvim/site/pack/packer/start/orgmode
git log
That should show you the last few commits on the branch that is currently checked out. If you don't see a reference about the :LOGGING: property in the commit messages then packer hasn't done something right.
@chuck-flowers, I just wanted to say that I'm incredibly sorry for not answering anymore. That's something I usually don't do.
Even after double checking that I'm on the right branch as you suggested, I couldn't make it work and figured I had another problem. Before getting into debugging it, well, life happened and I just didn't find the time to get to it. And I probable won't the sometime soon. Just wanted to let you know, I didn't forget about it.
I also saw that you've opened a pull request and are in the process of getting it approved. So, I'll try to stay updated. Thanks again for working on it.