Specific Tag Support (not solved by #255)

[ammunk]

First I wanna thank you for this awesome package!

Brief Abstract

Adding tag support (not solved by #255):

• Separate insert function for tags (thereby only suggesting existing tags)
• Separate org-roam-tag-title-format that serves a similar function as org-roam-link-title-format but for tags

Long Description

While trying to set up my workflow for incorporating tags and following the suggestions in #255, those solutions don't actually differentiate between tags and note files.

Problems with following #255 for creating tags:

1. calling org-roam-insert will mix tags and notes in the suggested list.
2. I cannot filter on tags using org-roam-link-title-format as any function passed to org-roam-link-title-format can only take title as argument, hence any template used for tags won't add a "tag identifier" to that title. This would enforce me to manually add a tag identifier to my tag files.

By adding a separate 'org-roam-insert-tag' function it could solve problem 1, and a separate org-roam-tag-title-format would solve problem 2.

Proposed Implementation (if any)

I was thinking something like treating tags just like notes, but placing them in a tag folder inside the org-roam folder. Also when adding a tag, give them a special entry to the database which can be filtered for suggesting tags when calling org-roam-insert-tag.

org-roam-tag-title-format should work just like org-roam-link-title-format but specifically for tags.

Please check the following:

• [] No similar feature requests

Thank you for considering this and for making this package! I hope such a feature could be added as I think specific support for tags would be awesome. This package has everything I need, but tag support is "the last thing I need".

[bennyandresen]

I would like to comment on this as I'm also trying to figure out a workflow that involves tags as a meta-notes feature, that at this point in time I find useful. (It may not be when everything gets huge.)

A bit of background

I started using notes that I used as tags in the notes preamble.

The problem I identified is that I had tags and notes for the same content. I have Emacs as a note and I have #emacs as a tag, because I associate a lot of things with Emacs and don't want to write that something is for Emacs in the note itself.

I disliked this approach because it is redundant and you may split associations in weird ways.

Counterproposal

I collapsed all my notes that also worked as tags into a single entity. So for example Emacs and #emacs became just Emacs.

This seems more like what RoamResearch is doing. Anything can become a tag. Because it's not obvious that notes can act as tags I have modified the faces of Notes when used as tags.

Both the #emacs under tags and Emacs point to the same file.

I agree that there should be helper functions that add tags quickly. In my current use case it just needs to prepend # in front of the description of the org-link at the appropriate place in the file.

Thoughts?

[ammunk]

I thought about that also but it just didn't sit right with me. My main concern is the searching and filtering for potential tags when inserting them (and generally keeping track of tags). If every note should be treated as a potential tag, then a tag insertion would should all notes instead of just tags.

In your Emacs example I agree that not differentiating between notes and tags makes sense, however I don't want to always treat a tag as a note. I typically would want my tags to be empty except for the tag name. For instance a tag like "personal life" would (for me) not contain any content and having it around as an actual note seems weird to me.

Basically I think tags and notes serve different purposes and I think my proposal could be a minimalist way of introducing a tag concept :)

Although your solution definitely makes sense and with helper function this may be the preferred way to go :)

[bennyandresen]

I can see how just having every Note be a potential tag can be overwhelming from the UI experience.

But because I think this is all convention anyway and in the end it's just links and backlinks one can look at how the tag insertion helper function should look: (Sorry if I high-jack your issue for this, I can drop it)

I think this filtering to only "active" tags could be done in several ways

• The for a tag-note to show up the #+TITLE or #+ROAM_ALIAS property has to start with a specific char like in my case #
• org-roam not only tracks the backlinks, but also with which description they were backlinked so a Note that was referenced with # is also offered in the tag insertion, despite not having it as the TITLE or ROAM_ALIAS
• A small snippet that converts a regular Note link to the Tag syntax for better UX when using a Note as a tag for the first time

[Wetlize]

I think the issue can be solved once all commits mentioned in this post will be merged. The workflow would work like this:

1. (setq org-roam-title-include-subdirs t).
2. Create a dedicated for tags sub-directory, e.g. tag/.
3. Create a dedicated capture template that will be responsible for storing tags, e.g. :file-name tag/${slug} :immediate-finish t.
4. (Optionally) Write custom filters that will only include tagged entries. This feature was introduced in https://github.com/jethrokuan/org-roam/commit/ba80a31fe0ddb48d41c446560c35c5677214a6ce.
   • Alternatively user can just type tag in the minibuffer (assuming he has ivy or helm) and it will list all tags without having a need for dedicated filter commands.

You can try out this workflow already using this temporary fork.

[ammunk]

@Wetlize This certainly seems like a viable solution. I'll close this seeing as once stuff in #520 gets committed that should do the trick.

[zaeph]

@Wetlize This certainly seems like a viable solution. I'll close this seeing as once stuff in #520 gets committed that should do the trick.

Everything has been committed now.