Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Allow Agenda.tags to list TODOs only #23

Merged
merged 6 commits into from
Jul 5, 2021

Conversation

chuwy
Copy link
Contributor

@chuwy chuwy commented Jul 4, 2021

Hello!

Just a small disclaimer:

  • This is my first Lua code ever
  • This is my first Vim code in 6 years
  • I have very small experience with org-mode
  • I generally have no idea what I'm doing

This PR allows users to filter only TODO items with specific keys by:

:lua require('orgmode').action("agenda.tags", { clear_search = true, tags = "personal", todo_only = true })

Above, the second argument becomes a table allowing Agenda.tags function to be non-interactive and filter only TODOs. I'm not sure if this is how it supposed to be - I see that you tend to be very conservative in representing Emacs behavior, but I needed that functionality and decided why not.

I couldn't find if Agenda.tags used anywhere with passing boolean explicitly.

P.S. That's a great plugin, thanks!

@kristijanhusak
Copy link
Member

Hi!

Thanks for the contribution. Code looks ok, no much complains there.

I investigated a bit how orgmode does it, and noticed there is an Agenda option M (we have only m here), which does exactly this. It searches tags only on unfinished tasks.

If you want, I can guide you through code review how to add the new option and provide this functionality, or I can introduce it myself and close this PR in favor of that.

@chuwy
Copy link
Contributor Author

chuwy commented Jul 4, 2021

Hey @kristijanhusak!

we have only m here

That was actually the place where we were passign a boolean explicitly! Fixed it.

If you want, I can guide you through code review how to add the new option and provide this functionality, or I can introduce it myself and close this PR in favor of that.

That's obviously completely up to you - I'm happy to get my hands dirty with NeoVim. There's one thing though that I think is really worth to preserve - a non-interactive way to call the function. I personally really dislike org-mode menu and keen to use which-key for these purposes.

@chuwy chuwy force-pushed the feature/todo-plus-tags branch from 8c78cdc to e359660 Compare July 5, 2021 06:28
@kristijanhusak
Copy link
Member

@chuwy I'll merge this, since it implements the missing feature. Note that I'll update it a bit to not access todo only tags via agenda.tags, but I'll instead expose a different public method called agenda.tags_todo. I'll leave tags property on both so it can be overriden on demand.

Thanks for the PR.

@kristijanhusak kristijanhusak merged commit f560d3c into nvim-orgmode:master Jul 5, 2021
@chuwy
Copy link
Contributor Author

chuwy commented Jul 5, 2021

Thanks, @kristijanhusak! I'm planning to start working on org-journal functionality somewhere later this week. Please don't hesitate to tell me if I need to change something in future PRs or that the functionality isn't what it supposed to be.

@kristijanhusak
Copy link
Member

I pushed the change. You can use it like this for regular tag view:

:lua require('orgmode').action("agenda.tags", { tags = "personal" })

and for todo tags like this:

:lua require('orgmode').action("agenda.tags_todo", { tags = "personal" })

@kristijanhusak
Copy link
Member

You mean this ?

I'm not sure how much new code it will introduce, but if it's a bit too much, you should create it as a separate plugin. Idea is to have built in only what orgmode has in core, and anything additional should go as a plugin.

I'll think about the plugins infrastructure and how we could expose some api for plugins. Do not hesitate to add some suggestions on #26 regarding this topic.

Once you have something working let me know to check it. I would love to expose a public API that will be stable, since this is still in beta, and some changes regarding the parsing will probably happen.

@chuwy
Copy link
Contributor Author

chuwy commented Jul 5, 2021

You mean this ?

Yup.

I agree that public API should be the way to go. I'll start doing this separately and let you know what issues I stumble upon.

gzagatti pushed a commit to gzagatti/orgmode that referenced this pull request Oct 19, 2022
SlayerOfTheBad pushed a commit to SlayerOfTheBad/orgmode that referenced this pull request Aug 16, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants