dmitrym0/org-hyperscheduler

[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

This is a great idea.

I have the org-roam folder and the gtd one completely separated. The tag creates a little noise into my already defined tags (also, it's the biggest one).

Maybe the tag/property could be activated only if the agenda file is inside the org-roam-directory. WDYT?

image

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 the gtd 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.