Adds support for :LOGGING: property#584
Adds support for :LOGGING: property#584chuck-flowers wants to merge 10 commits intonvim-orgmode:masterfrom
Conversation
|
I just realized that master has moved forward since I opened the PR. I can rebase this onto master unless that will cause a problem |
9e52d2f to
bf8f9c9
Compare
|
I've rebased on the latest master since git was reporting that there was a merge conflict |
bf8f9c9 to
f82b217
Compare
kristijanhusak
left a comment
There was a problem hiding this comment.
Thanks for the PR! And sorry for the late review.
The code looks generally ok, but as I mentioned in one of the comments, I think we cannot do file/headline level todo keywords at this moment. It needs many more changes in order to work properly.
Adding support for @ and ! in the todo keywords is already a great addition, so I would like to scope this PR to that.
| @@ -0,0 +1,69 @@ | |||
| local M = {} | |||
There was a problem hiding this comment.
Let's move this file to lua/orgmode/parsers/utils.lua.
There was a problem hiding this comment.
I've renamed the file as you've requested
lua/orgmode/org/mappings.lua
Outdated
There was a problem hiding this comment.
Having headline or file scoped config for todo keywords requires many more changes across the codebase to be properly considered. It will work on state change, but agenda, highlights, etc. will not work as expected.
Can we have this PR only handle @ and ! in the todo keywords and leave the file/headline level todo keywords for a different PR?
There was a problem hiding this comment.
I reverted the 2 commits which targeted the mappings file. If I remember right, this shouldn't affected parsing the "global" config value, but I will reconfirm this with my personal usage tomorrow.
f82b217 to
9dcdb41
Compare
9094379 to
abff0dc
Compare
Updates the type annotation for the `DefaultConfig` type to specify the allowed values of org_log_done for the Lua LSP. The values that are specified are based on the currently documented values for `org_log_done`.
Adds a method to the `TodoConfig` type to make determining whether to log a time, note, or not log at all for a give TodoConfig easier.
Remove the LOGGING property logic from the sections and the file-level.
9dcdb41 to
0e9437d
Compare
|
@kristijanhusak I think I have addressed the requested feedback. Please let me know if I have missed something |
kristijanhusak
left a comment
There was a problem hiding this comment.
@chuck-flowers This PR now just introduces a TodoConfig parser without actually using it? Is that intended?
I thought we will incorporate it to work with the todo keywords defined in the global configuration.
I'm ok doing that separately, and have this only as a refactor + preparation for the next PR. Just want to confirm that is the intention.
Could we have a unit test that tests todo-config file to ensure it parses everything properly?
44754e8 to
5143eed
Compare
ae38aa8 to
de701e8
Compare
Addresses issue #466 by adding support for the
:LOGGING:property to the note/timestamp insertion logic when updating the TODO state of tasks.I factored out the parsing framework I created for adding date property support to the agenda search. I used this framework to parse the syntax that orgmode describes in its manual for the
:LOGGING:property. I then, determined whether to insert a timestamp or note by first checking for the:LOGGING:property on the affected section and then using the property defined in the user's orgmode config.