Org-roam major redesign

So far, I was using org-mode mostly for task management, but now decided to use it for all my writings…however in the past I did experience slight wrist pain when using Emacs extensively which was never the case with vim - that’s why I am considering to use evil-mode, but that probably means switching from vanilla (I’ve working setup use-package declarations) to Doom considering that I’ll probably not be able to map evil as good as it was done by Doom.

Besides writing content using org-mode markup, I’ll probably just do some web stuff (using PHP/HTML/CSS), so wonder what do you think about Doom/evil for someone familiar with basic Vim familiarity due to ergonomic reasons? (Probably, I can stay with V1 of org-roam if there are no important reasons to switch earlier.)

Another option would be to stay with vanilla and maybe use god-mode…but optimal org-mode/org-roam are most important parts of my setup?

@gour, I would need to invite others to jump in to comment.
I don’t know vi/vim (I’d need to google to know how to quit it).

Why not try Doom? Given the person-specific nature of note-taking and Emacs, I don’t think we could know what is optimal for you before you try it. You can keep the current settings as backup; you can always come back if you don’t like Doom. You could potentially come back and copy its evil settings.

From my Doom experience, I believe you could use the normal use-package as it is. Doom has its own macro to extend it with use-package!—note the exclamation mark at the end, which indicates Doom-specific macros—but I don’t believe you need to use it.

Something like settinng aside 2–3 hours should be enough to get the taste:

  1. Backup current .emacs.d; install Doom (30–60 min waiting, I think)
  2. Read Doom documentation (especially on its special package management with straight.el and commandline doom -sync etc. (60–90 min)
  3. Use Org-roam, and play with Doom (30 min or so?)

Well, so far so good - configuration was pretty straight forward, but to be honest I’m still getting my head around the best way to use roam.

In my work life, I have a lot of meetings during the day related to different projects, so I’d like to track those with people that attended, subjects, etc. as possible links. I know most don’t seem to use org-roam for agenda purposes, but after reading @d12frosted’s interesting series, I feel I could have a good use case to do so. I have to admit, his setup is quite advanced and also relies on quite a bit of customisation…but getting my head around it.

One of my personal interests is apologetics/debating - I have hundreds of org files will notes & writings to support this. I am trying to come up with a way to ‘cut up’ these larger files into specific knowledge snippets, add them to org-roam, then use your transclusion package with a view to building a specific larger file with the org-roam snippets transcluded into a master document for a larger subject by selecting the org-roam files through tags…

Probably a bit off-topic with the specific use cases - to wrap up - in the very early stages, but v2 appears to functioining well. I’m quite the neophyte still, but will provide more specific feedback on v2 once I’ve had a chance to really build some experience with it. Keep in mind, any feedback I provide will be lacking the perspective of having used v1.


I’m also experimenting Org-roam for work with meetings (in my case, usually specific topics; people are “attendees” but won’t be a tag for me).

I would also love to emulate @d12frosted’s elegant custom approach, but not there yet. My simple approach at the moment is to create an “index note” for a topic, and in every meeting note I link to it (or from it – not consistent at the moment). With V2, perhaps I could have one file per topic, and create heading in the time line. It looks conceptually like this:

:properties: ...
#+title: Meetings on Pricing for Product A

[[id:xxx][Index: Pricing]]
[[id:yyy][Index: Product A]]

* [2021-01-31]
:id: id
Action items:
* [2021-02-28]
:properties: ...
Action items:

Yep - I like where you’re headed with that. I’ve already got a meeting template for my dailies-capture-today - but it’s quite basic. I have ‘visions’ of being able to choose variations of capture templates that prompt for certain pieces of metadata that would then be stored as a tag (or perhaps an id as in your example) for quick, consistent capture.

The more I think about the use cases for org-roam, the more I feel it can replace many of the ways I manage data right now - probably it needs some kind of context switching built in to broaden this type of functionality where there is a good reason to silo information that is totally unrelated, but with that context switch may come different capture templates purpose built for that task…

When I have some more concrete work done, I’ll be happy to share how I use org-roam and would love to provide some ‘plugins’ that I have in mind. Now, just to find the time!

1 Like

@snappahead Indeed, setup I am describing in that series is not the simplest one. And as you see, it is focused around people and meetings with them. Don’t hesitate to contact me to discuss this problem and available solutions :slight_smile: Or even if you simply have questions regarding the flows I am describing :smiley_cat:

I haven’t yet described my capture flow for meetings, I am still experimenting with it. But it might interest you. In short, when I capture a meeting, I can select a person, so my meetings notes go straight to that person file. If I don’t select a person (I can type anything), it goes to my inbox file. I treat all meeting notes as completed tasks, but I put ‘REFILE’ tag on them, so I see them in my agenda (under inbox). But it’s easy to configure it in a way that it puts all meeting notes into inbox file, but tags them depending on a person (or even mutiple people) you select. If anyone is interested, I can describe the flow and possible variations.


@d12frosted , this is fascinating; I would be interested in the “flow and possible variations” – perhaps in your next blog post :wink:

One quick question, if I may… How many people do you have?

If I were to start tagging each person I tend to meet with, it would be more than a tribe that a human can meaningfully remember (more than 150; if you subscribe to this ideas :wink: ).

A “person” for me tends to represent a topic, customer, or a business unit – so individual names are not very important as an index or tag; what they represent is more meaningful—hence I have index files for them.

It seems to me that for your situations individual persons carry much more weight and meaning.

Here’s a version that avoids a regexp search in the unhide side of the toggle. The remaining regexp is also case-insensitive.

Edit: this code is now moved to the Hitchhiker’s Rough Guide to Org roam V2


:smiley_cat: Cool, if you are interested, I will describe it some time

I have a quick answer for this question :smiley_cat:

ELISP> (length (vulpea-db-query (lambda (n) (seq-contains-p (vulpea-note-tags n) "people"))))
241 (#o361, #xf1)

Sometimes on a rare occasion I delete them, though, once I decide that
there is no value in keeping a file for that person.

In reality, I meet around different 40-50 people each week and up to
80 people per month. And most of these meetings (not sure about
concrete numbers) have outcome in form of action items (regardless of
executor) and some thoughts. In any case, this is something I need to
digest afterwards, so I want to see these notes in the inbox.

Haha, my memory is even more limited. I hardly can keep 20 people in
my head, that’s why I use org-mode with org-roam :smiley_cat:

Well, roughly speaking, a person is just another context. When I am in
a meeting with a person, I want to have ability to quickly write
meeting notes that will stay in my visibility until I mark them as
digested (e.g. they are no longer in my inbox) AND to see any tasks
related to this person.

I agree that context can be anything, person or a project, or a
business unit, or whatever. In practice, I treat most of the people as
projects :slight_smile: Because I have TODO entries related to them.

Now thanks to you I want to experiment a little bit more with various
contexts. :slight_smile:

1 Like

amazing! I’d love your version to be part of the wiki :). perhaps next to the text property version i did (i don’t mind my version to be overridden; do as you wish). if you don’t have time this week, I might come back to it this weekend…

I’m most certainly interested - but I thought I would create a separate thread for this purpose. While I think it is relevant to the v2 discussion, its is perhaps beyond the scope of the core functionality of org-roam. You can find the thread here.


I’ve never used Vim myself until I started to use evil-mode in Emacs and that long before I heard of Doom or Spacemacs. I then learned about Spacemacs and switched to it to have a painless Evil config. Then to Doom when it came to the scene. So I can’t tell it from the perspective of a Vim user. In fact, I often struggle with Vim – and I use it regularly for quick edits on the command line or to troubleshoot my Emacs config when it is broken – for example hitting M-q to fill the paragraph, which obviously does not work in vanilla Vim. I also had to learn a few essential Vim commands like :edit or :bnext, because in Doom I would use the leader shortcuts SPC f f and SPC b b (instead of Emacs’ C-x C-f and C-x b). Evil however provides a large subset of : commands, so I guess you’ll feel at home right from the beginning before gradually adopting some of the Emacs keybindings and leader key sequences.

I think Spacemacs and its spiritual successor for the Evil part, Doom Emacs, are the most flexible environments. So I use Vim keybindings hjk etc. for motion and visual mode editing, which is the best way to edit text in my opinion, leader key sequences for the most often used commands like SPC b b and vanilla Emacs key chords for anything else still in my muscle memory like M-q or C-x 3.

Thank you very much!

Heh, :gqip is one of my favorites in regard. :wink:

1 Like

Selectrum + Embark (and which-key) w/org-roam.

; org-roam v2 keymap

(defvar my-org-roam-map
  (let ((map (make-sparse-keymap)))
    (define-key map (kbd "t") 'org-roam-buffer-toggle)
    (define-key map (kbd "i") 'org-roam-node-insert)
    (define-key map (kbd "f") 'org-roam-node-find)
    (define-key map (kbd "r") 'org-roam-ref-find)
    (define-key map (kbd "g") 'org-roam-show-graph)
    (define-key map (kbd "c") 'org-roam-capture)
    (define-key map (kbd "j") 'org-roam-dailies-capture-today)
  "Keymap for 'org-roam' v2.")

; make available my-org-roam-map to embark-act
(add-to-list 'embark-keymap-alist '(org-roam-node . my-org-roam-map))


OK, it’s added. Thanks, by the way, for setting up the wiki.

1 Like

On the tags section at the end, and source code example, I thought (looking at the source code) we should get annotations by default, if not customized ones of course.

But I’m not seeing any. Is anyone else?

Do you mind expanding on what you mean by “annotations”?

This is done by what I take to be annotations. Same thing?

Yes; via the completing-read annotation-function.

Thank you. Then… as you can see tags are added to annotations by V2. They need to be Org filetsgs or tags.

I think the issue was the tag names need to be lower case. With that change, I now see annotations.

BTW, that code you added to advise the annotation-function is helpful!

1 Like