Skip to content
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

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.

lua/orgmode/agenda/init.lua Outdated Show resolved Hide resolved
@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants