Is there a bug with `org-roam-tags-completion`?

I have started playing with org-mode tags hierarchy lately, and I noticed that when setting org-tags-alist, most of the list keywords like :startgroup are added to the completion list.

Looking at the org-roam-tags-completion code, it seems it is only avoiding the :newline keyword. Simply adding a few cases in the function work on my end. This is a working slightly modified version of org-roam-tags-completion:

(defun +org-roam-tag-completions ()
  "Return list of tags for completions within Org-roam."
  (let ((roam-tags (mapcar #'car (org-roam-db-query [:select :distinct [tag] :from tags])))
        (org-tags (cl-loop for tagg in org-tag-alist
                           nconc (pcase tagg
                                   ('(:newline)
                                    nil)
                                   ('(:grouptags)
                                    nil)
                                   ('(:startgrouptag)
                                    nil)
                                   ('(:endgrouptag)
                                    nil)
                                   (`(:startgroup . ,_)
                                    nil)
                                   (`(:endgroup . ,_)
                                    nil)
                                   (`(,tag . ,_)
                                    (list tag))
                                   (_ nil)))))
    (seq-uniq (append roam-tags org-tags))))

Steps to reproduce:

  • Add some tag groups to org-tags-alist; Below is the example from the docs:
(setq org-tag-alist '((:startgrouptag)
                      ("GTD")
                      (:grouptags)
                      ("Control")
                      ("Persp")
                      (:endgrouptag)
                      (:startgrouptag)
                      ("Control")
                      (:grouptags)
                      ("Context")
                      ("Task")
                      (:endgrouptag)))
  • Call org-roam-tag-add

When I follow these steps, all the list keywords such as :grouptags appear in the tags list.

Can anyone reproduce ? and, if yes, does the version of org-roam-tag-add I provided earlier in this post fix the issue for you too ?

Should this trigger what you observe?

 (setq org-tags-alist '("tag1" "tag2"))
(org-roam-tag-completions)

it does not in my configuration.

I don’t use Org files and tags in Org, but M-x org-roam-tag-add gives me this list. All familiar tags and nothing that seems to be automatically added by Org…

Sorry I know I am not responding to your exact question, but this is probably what the default list of tags look like if you don’t configure it.

@dmg @nobiot
Sorry, I had omitted the ‘steps to reproduce’ in my post. I updated it if you guys want to have another look at it.

ok, i see them now. DO you have a link where I can read how they can be useful?

About fixing the code. I know this is not code that gets executed very frequently, but… pcase are macros that when expanded create garbage. I would avoid them in favor of cond and member

You can read about tag hierarchy in the orgmode manual ; The ‘Tags hierarchy’ link is the most relevant, but the previous one ‘Setting tags’ also gives some context.

I find them very interesting on a workflow standpoint. Combined with org-fast-tag-selection and org-current-tags-alist they allow the creation of arbitrary lists of tags based on programmatically defined contexts or conditions. I think they have great potential for an efficient workflow and consistent tagging conventions.

As long as filetags are not supported, I find it impractical to use with org-roam, so I went with another approach in the meantime. I stumbled on this “bug” while experimenting, so I thought I should not ignore it though.

Thanks for the info on pcase, I am just learning Elisp, so the code I provided is a slight modification of the org-roam-tags-completion function which I think foresaw this edge case, and simply overlooked some of the keywords. This is not my code per say :slight_smile:

Thanks, this is useful.

I tried and filetags seem to be supported. They worked for me.

I have been using prefixes for my tags (eg: p_ for project, pe_ for person, @_ for location, etc. But this will add an extra layer. Although the problem is that they are mostly useful in combination with the agenda files (as opposed to all the org-roam files).

oh, one more thing. If it really bothers you, you can replace the function using an advice. That way you don’t have to modify org-roam.

I wrote too fast. I meant that org-tags-set-* commands did not support filetags. At that point I was focusing on tag setting from a workflow standpoint. I use some tags to signal an action required on a note, or a status for example.

My main objective at that point was to present reduced lists of tags on specific conditions. With the help of NickD on StackExchange, I got around a way to set up list of tags within a function, withhout defining them globally in my config. The bonuses of org-fast-tags-selection and tags hierarchy to offer grouping and mutually exclusive tagging really added a lot of value to this approach. Because I had to use different UIs for tagging header, and file nodes I gave up on it temporarily.

Of course, using this feature for its filtering capabilities is very interesting as well (and its primary reason to exist I think). It is one more answer to the recurring need/requests for hierarchical tags in note taking (especially zk based solutions). I have not gotten to that part yet, nor have I felt a great need for it with the agenda files. The prefix trick is a nice solution that can cover a lot of use cases I agree.

Thanks, this is what I went with. The main point of me asking here was to find out if it was only affecting me, and maybe get some advice on what to do if it is actually a bug. Should I report it on the github project page ?

You actually gave me an idea of writing some kind of succession of completion-read wrappers to select tags hierarchically based on the org-tags-alist. Selection could then be processed to pass the ‘children’ tags to an org-roam-node-find FILTER-FN…

Just a thought .

yes, you should.

1 Like

I use the TODO labels for actions, projects and areas (F for finished, S for suspended) and tags to cross-reference them to other types of information (locations, persons, projects, etc). I also use org-edna to change the status of a TODO to NEXT when I complete a task.

((“TODO” “NEXT” “WAITING” “SOMEDAY” “PROJ” “TOFILE” “STARTED” “DONE” “AREA” “CANCELLED” “FPROJ” “SPROJ”))

Usually an area or a Project will live in a single file (small areas/projects might share the same file). I use the hierarchy. of headers to determine which actions belong to each project.

And one more thing. I use inheritance of tags. So any header under a Project or Area inherits the p_ tag. so that way I can easily search for a project heading using org-roam-node-find (my template has tags, olp, title, todo and file).

Thank you, it is very interesting to see how other users handle the same problems. I have a similar general organization with also a little GTD, and a little PARA in there (I am guessing that is where Areas come from, since I am using this concept as well).

My ‘action’ tags come from the fact that my genral workflow is still under heavy development, as well as my ‘work habits re-programming’, I am still looking for an efficient way to add note maintenance tasks in the agenda while keeping it useable. In the same spirit, I use statuses for the common DRAFT / WIP / ARCHIVE notes lifecycle, but also for project development stages.

I spend a lot of time developing a project in my notes before breaking it down into actionable tasks, and I try to only store task headers and checkbox items in the agenda files. So (for now), I use tags to signal roughly what is the project development stage (initial research or feasibility analysis, requirements definition, technical specifications, task planning).

I use hooks to mirror these note tags to their matching agenda files project items because I have not come up with a better way yet, and I do not know how to fit tasks about planning other tasks in my current agenda files structure…

How funny,. Yes, that is how I describe my method.

But I do keep the tasks under a “tasks” header in my areas and project files. The way I “connect” them to the agenda is by dynamically generating the agenda’s list of files from org-roam.

I have a tag that is dynamically generated: if a file has NEXT or TODO actions, a filetag is added/removed automatically.

That way the tasks are not spread around, as they live where the “belong”. My agenda files list is around 20 files which is still manageable. Though I only use it for scheduled tasks, most of the time I am simply going to the area/project file when I need to do work on it.

For ephemeral tasks, I keep a “daily” file (which is actually is a weekly, but that is another story).

of course, this is work in progress.

I am new to Emacs, but I have been looking for a home to my notes and task management mess for years.

I tried a lot of great tools and methodologies, and after a while you realize we all end up with a mix of our favorite elements from the same frameworks. It is a bit like music, there is an infinity of melodies we can come up with, but not that many notes to begin with :slight_smile:

I do borrow a few terms and ideas from AGILE or Kanban as well, but at the end “taskeinstein” does not look like any of those framework. This is what I love with Emacs, org, org-roam, there are a lot of tools, great functionalities pre-made but you put it together and modify the way you want/need. It is like nothing I tried before; the time spent in the infamous learning curve is sizeable, but it is an investment because at the end you have what you assembled. If I could make the sum of all the time I spent configuring and learning tools to ultimately hitting a wall and giving up on it, I’d say Emacs learning curve is not that bad after all.

Anyway I like your concept of ephemeral tasks, I need something more flexible too. I was actually going to try the ‘Task’ header strategy for the project planning notes I was talking about earlier. This way I can keep track of progress, but keep it off-agenda.

A work in progress indeed.

I fully agree about emacs. I have been using it since 1987 and the learning “cliff” (as I call it) was huge.

I see it today as my workshop: it is custom made for me and my idiosyncrasies, and it is always morphing. My git log counts 520 commits and that is only since 2016. And for me it is no longer an editor. It is becoming, like Tiago says, an extension of my brain.

Thanks for the discussion on workflow. We can always learn from each other, and don’t hesitate to ask for help. If you are learning lisp, I recommend a course in coursera (Programming languages, section 1 and 2) which gives a solidi foundation in functional programming, the second being racket, which is a close relative of lisp).

2 Likes