[Suggestion] Consider making the DO_NOT_ORG_ROAM tag into a property
Closed this issue · 7 comments
Issue:
The DO_NOT_ORG_ROAM
tag is visually distracting as it appears in most org-agenda
views. Hiding tags can be impractical as many of us use tags in our daily workflows.
Proposal:
Consider adding DO_NOT_ORG_ROAM
as a custom property instead of a tag. This property can remain hidden in the properties drawer but can still be accessed by org-roam-db-node-include-function
org property drawer API
I had the same problem, this is how I dealt with it:
(setq org-agenda-hide-tags-regexp (regexp-opt '("DO_NOT_ORG_ROAM" "MINE" "WORK" "IMPORTANT")))
Regular expression used to filter away specific tags in agenda views.
This means that these tags will be present, but not be shown in the agenda
line. Secondary filtering will still work on the hidden tags.
Nil means don’t hide any tags.
Your approach is better since it doesn't require any additional work. I'll add it to the "roadmap".
I have the
org-roam
folder and thegtd
one completely separated. The tag creates a little noise into my already defined tags (also, it's the biggest one).
Same.
Maybe the tag/property could be activated only if the agenda file is inside the
org-roam-directory
. \WDYT?
An optimal solution may be to have a user-accessible setting, maybe (setq org-hs-add-org-roam-ignore t)
I also think that this setting is more in-line with a property drawer than a tag.
Thanks for the ProTip on how to hide unwanted tags! Will use for the interim.
I'm also not a fan that org-hyperscheduler
modifies my org-agenda items without any explicit consent. So I think there should be a user-accessible setting and it should be opt-in, i.e. off by default. This package has nothing to do with org-roam, other users might not use org-roam and thus behaviour that has to do with org-roam should not be on by default.
If you want the tag-setting be on by default, I would at least ask the user on first invocation if they want this via a prompt and then save the answer for the future, for example in custom.el
.
A way for making it much more user-customizable would be to replace the org-set-tags
with a hook that the users can add to:
(defcustom org-hyperscheduler-post-id-hook nil
"Hook to run after an ID has been added to an agenda event"
:group 'org-hyperscheduler
:type 'hook)
Then in get-agenda
:
(defun get-agenda ()
"Get an org agenda event and transform it into a form that is easily JSONable."
(setq org-id-prefix "org-hs-id-custom")
(condition-case nil
(org-id-get-create)
(error nil))
(setq org-id-prefix nil)
(run-hooks ' org-hyperscheduler-post-id-hook)
[...])
And then add to the README.org
, under Hiding calendar entries from org-roam, add the line:
(add-hook 'org-hyperscheduler-post-id-hook
(lambda () (org-set-tags (org-uniquify (cons "DO_NOT_ORG_ROAM" (org-get-tags))))))
(require 'org-roam-protocol)
(setq org-roam-db-node-include-function
(lambda ()
(not (member "DO_NOT_ORG_ROAM" (org-get-tags)))))
Those who prefer properties could just add a property-setting function to the hook and set that as a filter for org-roam. You could also give an example for that in the README.
Hey @meliache, thanks for your suggestion. I spent a few minutes working on this today before actually seeing your comment.
In ea2aad3, I removed the DO_NOT_ORG_ROAM
tag in favour of drawer properties like @ifinkelstein proposed.
I like your hooks approach, but I'm wondering if it's too complicated. Do you have any other use cases in mind, where folks might want to use the hook? I'm leaning towards a flag (like this). Toggling a flag is much less error prone than having a hook.
@dmitrym0 No, I don't really have any other use-cases for the hook in mind. Though often the idea for those is to enable users to add behaviours beyond what the developer could imagine. In theory you could have both a flag and a hook, e.g.
(when org-hs-add-org-roam-ignore
(add-hook 'org-hyperscheduler-post-id-hook (lambda () (org-set-tags (org-uniquify (cons "DO_NOT_ORG_ROAM" (org-get-tags)))))))
But in this case maybe you're right to better keep it simple and just add a flag, here I also don't think I hook is really necessary. And if anyone wants to completely change the behaviour, it's emacs, they can just override or advice it.
This is now fixed in v0.1.3+4. If you get the latest version, you shouldn't have to do anything; by default adding ROAM_EXCLUDE
property is disabled.
If you do need ROAM_EXCLUDE
, customize-group
or the usual (set org-hyperscheduler-exclude-from-org-roam t)
should do the trick.