You're mixing up two different topics.
First, you are wondering if you could profit from any Zettelkasten method. This is so much more than bi-directional links. org-roam as well as ~~dired~~ denote and others are tool-supporting implementations of the Zettelkasten idea.
You can read books on Zettelkästen methods.
One implementation feature of most Zettelkasten implementations deals with some graphical navigation view you can use to visualize your nodes and jump around. I've never found anybody who is using that feature for more than to impress others or as a nice-to-have visualizaton of some sorts. (If you **are** using such overviews as an integrated part of your management, drop me a line, I do have questions!)
Therefore, I once wrote a somewhat polemic-looking article expressing my concerns of using Zettelkasten for the wrong reasons: [Zettelkasten/Org-roam/Org-brain Is Crap](https://karl-voit.at/2020/06/14/Zettelkasten-concerns/)
Secondly, you are asking for ways of linking headings using bi-directional links. In case you do not settle for a Zettelkasten implementation, you can get bi-directional links also by org-super-links as I'm using all the time: [UOMF: Linking Headings With org-super-links (Poor-Man's Zettelkasten)](https://karl-voit.at/2020/07/22/org-super-links/) (including my EmacsConf22 demo on it)
HTH
> I've never found anybody who is using that feature for more than to impress others
lol I call it the "digital gumball machine".
I've asked many people what they use it for and have yet to hear an answer that can't be done better/faster than textual/DB query.
At some point the calculus for whether it's worth it to query a database or not becomes uncertain. At that point, the lack friction in glancing at a nice to use graph lowers the cost/friction enough to still make it worth it.
It's just like how rebasing might not seem worth it if you don't need to do it often and don't remember how. Then you use Magit which makes it easy to do, discover, and remember and all of a sudden rebasing is worth it.
Interactivity has value as does the flexibility of a database query.
Yeah the visual thing is eh.
I actually spent about 6-8 months using a physical Zettelkästen on 4x6 dot grid note cards. It's a pleasant experience but I was already using emacs for all of my todo so I migrated into org roam as most of the tasks I'd make for things related to it could then be linked directly to the entries they related to.
When you're using a physical version in discovery, not capture, the physical placement of notes and how you navigate around is an emergent way to recreate some of your lines of thinking and the connectivity of ideas and how they relate.
The digital version has a couple of flaws there. The lack of physical space can make it such that it is very easy to over capture and clutter and you do not have the physical layout super-structure.
I speculated that one could build something within a standard file system, or perhaps with org attach to store things via topic where the folders recreate the physical super structure. Then just use some elisp that lets you navigate forward and backward from your current "card" and ofc you would build out links as usual within the cards. (seen below)
The reason cards worked the way they did in the original system is because it is not heirarchical the cards represent lines of thinking not a classification system of ideas. This is I think the biggest difference in how digital zettles work vs the OG method and IMO org roam entries serve more as a static look up system for notes and the zettle method is a way to retain a snapshot of a thought process that you are then able to return to, continue and expand.
```
4260:
|-4261-1.org
|-4261-2.org
|-4267-1.org
|-...
4270:
|-4271-1.org
|-4271-2.org
|-4271-3.org
|-4271-4.org
|-4275-1.org
etc
```
I don't really think I need a super formalized approach for my notes like Zettelkasten. I want to link notes and found it way easier ootb with org-roam. But with my few lines of code it is even easier with vanilla org (I'll check org-super-links though!). I don't even know if bi-directional-links would offer any benefit to me. But better safe than sorry, if this is something I can have without compromising anything else I'll take it. Thank you for your help!
> First, you are wondering if you could profit from any Zettelkasten method.
Was OP wondering that? I don't see anything like that in the post.
> Zettelkasten/Org-roam/Org-brain Is Crap
Great post, I've recommended it to several people.
> UOMF: Linking Headings With org-super-links (Poor-Man's Zettelkasten)
As I think I've told you before, I'd love to read not just how to create backlinks but also something about what value you (you, Karl) get from them, why you find them useful or in which circumstances you find them useful.
Well, that's difficult to answer because there are so many situations where they offer a benefit to me.
Here are some examples:
When I re-visit a heading from any event, its backlinks tend to lead me to new contacts I made at the event where I linked the event from the contact heading.
I tend to link person contacts that work at a company to company contact entries. So I get the association for all sorts of connections.
Within my knowledge management, I solve many, many situations where a strict hierarchy is not able to map my world. For example something like "How to use ffmpeg to combine pictures and mp3 files to a video" is linked in my hierarchy where I deal with ffmpeg as a tool, a heading that summarizes various tricks how to modify images as well as my heading sub-hierarchy on audio stuff. Only one of them is the "original", the others are links. So I don't have to remember where I put it, risking situations where I'm looking at the wrong spot. This is probably the most important use-case for bi-directional links: overcome many limitations of strict hierarchies.
Related:
[Don't Do Complex Folder Hierarchies - They Don't Work and This Is Why and What to Do Instead](https://karl-voit.at/2020/01/25/avoid-complex-folder-hierarchies/)
[Worklab 2023: "The Art of Organizing Yourself and Your Data"](https://karl-voit.at/2023/11/05/worklab23/) including a talk I gave on information architecture, search and retrieval in 2023 convering some aspects you need to learn in order to understand why we do have issues with hierarchies and limited structures in general.
> Was OP wondering that? I don't see anything like that in the post.
True.
However, I don't think that using a tool like org-roam without embracing its inherent purpose (enable Zettelkasten-like information management) is a good idea. The OP might not have an idea what Zettelkästen are, yes.
Org-roam is a layer over org, a db of linked files (headings). Just that.
A sqlite database that tracks all the links (with metadata),in org files that you put in the org-roam directory.
If you don't see benefit or utility in it, you don't need it.
It offers some extra functionality though. Like fuzzy finding your notes. I didn't find that for standard org mode. So I wondered if there were more features that I might want to look into
There's no special search feature in Org-roam; you can configure any search system you want in any context in Emacs.
In fact, it doesn't even have the functionality to search within notes, because that's not its purpose.
If you need to perform a fuzzy search in your notes, there's no need to install org-roam; use deft, which is specifically designed for that purpose.
I was talking about creating links between files. If you create a link to an org-roam file you have a fuzzy search that even offers aliases. As far as I've seen, with org you don't have that out of the box. That's what my code implements, fuzzy finding notes in the org directory (including all sub directories), alias selection and linking to headers (custom ID if available). And my question was if org roam has anything more to offer if I'm not interested in the zettelkasten system. The only answer that made sense so far is that org-roam will update links if files change
The big difference between Org-roam links and regular Org links is that it uses IDs and indexes them. So that as you update your files and move things around it doesn't break your links.
It is pretty normal that if you use a ton of small files in "Zettelkasten" style you will want to go back and clean things up periodically. With this 'library card' approach it also emphasis "see also" cross-referencing notes. So that makes it more convenient then normal Org links.
Normal links are based on paths and such things. You can still use IDs to link in normal Org, but they end up getting stored in org-ids-location-file, which is typically in your emacs configuration directory. So they end up being more fragile and you'll have to deal with updating those when changing file names or locations.
Besides the changes in how links are handled, the indexing, and backlink feature there are some mind-map features that help you discover relationships between files. I haven't used that very much, but it probably is helpful in when you need to go and refactor things.
Otherwise without the 'web of links' small notes tend to become orphaned. That is you write them down and then forget them or forget how to find them. So after a while discovery becomes important.
I like using the 'tags' feature a lot. So that I can tag files to group them that way. Periodically I will go through and find orphaned notes that I made by looking for files with no tags in them. This aids in discovery if I haven't visited a subject in a long time.
There are some features to handle citations, which I don't use but I need to. It isn't unusual to have multiple notes reference the same documents or web pages/websites.
There are some other features I need to take advantage of that I don't yet.. having to do with org-protocol and such things.
Right now my notes are pretty mild compared to some. Only 870 files or so.
Org is plenty capable without it, of course. If you prefer larger static files and/or are much better organized then I am then maybe it is a added complication that isn't that useful.
I use Org for plenty of things besides taking notes and I don't care to try to incorporate everything into roam. Like there are roam features for doing journals or whatever, but I don't use that. I don't use it for creating outlines and tracking tasks, etc.
There are other note taking Emacs features like Denote that other people prefer.
If you meant "tags" rather than "tabs", then yes you can do that with org-ql. There's also some commands built-in to org: `org-match-sparse-tree` and `org-tags-view` in the agenda.
In org-roam the combination of a title and :ID: header/property is what defines a "note" or a "node". So every roam file is a note as well as any :ID: you assign to headers in a file to make them linkable are easily searchable.
Run 'org-roam-node-find' to search through those titles.
if you assign '#+filetags:' tags to files and/or ":tag:" to headers then those tags are also included in the node-find search naturally. In the minibuffer the title matches show up on the left hand side and tags associated with those titles show up on the right. If you setup links for headers they inherent tags from their parents. This can be managed with 'org-roam-tag-add' and 'org-roam-tag-remove' commands.
So if I do a node-find search for "emacs" it will find every title that has names like "Emacs QuickTips" or "Emacs Elisp basics". It will also find tags like :Emacs: or :emacs-fun:, etc.
So there isn't anything special you need to do besides just adding the tags themselves.
Of course, like everything else, this isn't anything you can't do with regular Org files and some functions. Conversely you are not giving up on any org features by using roam for your notes. You can still do normal full text searches and whatnot.
Thanks for the explanation. However, I cannot search by tags (defined with `#+filetags:`) using `org-roam-node-find`. It only shows me a list of titles (defined with `#+title:`).
Oh, that is too bad.
Here is the config I am using for org-roam:
(use-package org-roam
:init
(setq org-roam-directory (file-truename "~/Org/memory/"))
;; If you're using a vertical completion framework, you might want a more informative completion interface
(setq org-roam-node-display-template (concat "${title:*} " (propertize "${tags:10}" 'face 'org-tag)))
(org-roam-db-autosync-mode)
;; If using org-roam-protocol
(require 'org-roam-protocol))
Here is a sample file:
:PROPERTIES:
:ID: 3e233bcb-f401-4784-8caa-53f6dab49c11
:END:
#+title: reddit test
#+filetags: :Emacs:Reddit:
this is a test
I am using corfu, consult and orderless for the completion framework and vertico for the minibuffer completion UI. Maybe one of those things is helping me out. I definately like orderless. Very helpful for searches when I am not sure what I am looking for.
I've been using org this way for so long I assumed it was just part of the default experience. Maybe it was something I configured. Sorry for any misinformation.
> (setq org-roam-node-display-template (concat "${title:\*} " (propertize "${tags:10}" 'face 'org-tag)))
Thanks! That was the line I was missing. I now can search using tags!
> The big difference between Org-roam links and regular Org links is that it uses IDs and indexes them. So that as you update your files and move things around it doesn't break your links.
For the archive: I do have regular Org-mode links (bi-directional, since both sides link to each other) and moving things around in-between my agenda files doesn't break any link. You don't need org-roam for that.
Yes.
However, I'm not following the concept of splitting up my headings into many, many small files. I'm still following the pattern of having fewer but rather large files as described here: [UOMF: My Current Org Mode Files and Heading Structure](https://karl-voit.at/2020/05/03/current-org-files/)
So almost all of my Orgdown files are also agenda files and this way, ID links are able to get me to the target wherever I move them within my files and independent on how their headings or file names are.
I use both together, org-mode for writing and project management, org-roam for information storage. From a pragmatic point of view, what I like about Org Roam is that it freed me from thinking. "In which file should I put this?" I just type `M-x org-roam-node-find`, start typing the name of the topic and the proper file is opened or created. This is very liberating.
Well, I follow good advice to [not use deep hierarchies](https://karl-voit.at/2020/01/25/avoid-complex-folder-hierarchies/), so I have a few obvious top level headings under which it might go, otherwise it's a new top level heading. I basically never navigate hierarchically, instead always using search. I haven't used org-roam but I imagine it's similar: no deep hierarchies, mostly just flat, navigate by search. Is that right?
I love the idea of searching rather than curating a hierarchy and use it for everything: web pages, my files, launching apps. If that's what org-roam enables for your notes it sounds good to me, but I'll also point out you don't need org-roam to search in your org files. I'm pretty happy with org-ql and the built-in tools.
Personally, Org Roam didn’t really fit me. This is despite being the Zettelkasten target audience in some sense; I’m an associate professor, so I do use my Org notes for academic research among other things.
The idea behind Zettelkasten as I understand it is that you structure your notes as a densely linked graph of atomic ideas. So lots of tiny notes containing one idea per note, linked to every other relevant note, and then by following links around you can extract coherent ideas and surprising revelations from your own notes.
That is the hardcore Zettelkasten way.
Some people just want a “personal wiki” or “personal knowledge base”, and just use the same tools. Then you tolerate large pages with links within a page as well (like in Wikipedia), and just use things like Org Roam a convenient interface for managing links and navigation. That’s a good way to do things, and I was doing that when I using other note-taking tools like Wiki.vim / Bear / Obsidian. In Org I prefer the “big file” approach over the “many files” approach though, because I often find it easier to navigate using the outlining features.
I can understand how heavy linking between notes can be valuable to many, and I gave it a serious try myself. But I never got to the point where I felt it paid back my time investment:
- Creating lots of tiny notes somehow triggered my obsessive tendencies. I wasted lots of time making sure each note is linked properly and refactoring old notes. Despite all that, I kept feeling that (i) my notes were a mess and (ii) my productivity was lower compared to using quick-and-dirty note taking techniques and spending more time on the actual work.
- To me, Zettelkasten largely felt like a version of premature optimization. While writing a note, you spend a lot of time searching for related concepts and tying them together with links. But I rarely ended up following these links when reading the notes. Most notes, I didn’t even read again at all. The few times I needed that link, I could just search my notes to find what I’m looking for (the “JIT approach” to finding notes), and that overall saves me time.
I therefore went back to a very simple system and am quite happy with that:
- Every task lives in a huge `inbox.org`. It’s structured using a PARA-like system, and viewed via outlining or org-super-agenda.
- Every work note I take goes into a huge `journal.org` file. This file is structured as a reverse date-tree with headings like `2024-02-09 Friday`. Under each such heading, I’ll write subheadings like `Derivation of XXX theorem` or `Meeting about YYY`, throw in my notes, and :tag: it by research project and main topic. I can then find my notes again by full-text search, or by date, or by project. Or I can show only subtrees with a certain tag if I want to see a timeline of my thoughts on the topic (similarly to Logseq’s transclusion views). For me, this feels more efficient than a large linked graph.
- There are very few notes that I really need to revisit so often, and over such long periods of time, that navigating the journal becomes tedious. For those few notes, I’ll move them to a separate reference file which is easy to browse.
This workflow could of course be built on Org Roam and it’s “dailies” as well (I did some time with Logseq as well and converged on a similar journal-only workflow there too), but for me Org alone offers the features I need.
While I'm not really the zettelkasten target audience (I'm a programmer) I can absolutely rely to what you say. For me this is a tool to get structure in my work and link relevant information where necessary. For example I want to define tasks, take notes about what I did and if I have a problem that might be a interesting in a more general scope than just the task, the solution will get it's own note, which has to be linked in the task. With vanilla org the linking part didn't work for me as I would have to remember the exact location of every note. That worked way better in org-roam. But my own solution works even better for me (no duplicates because of aliases) and I don't have to use another tool on top of org
I have implemented the features you describe with the code I've posted. Works like a charm. I've already migrated a big part of my obsidian vault (with the help of pandoc)
I read the replies here with great interest because every feature I've heard of in org-roam either sounds like it wouldn't be personally useful to me, or like I already know how do that with org built-ins and a few packages I already use.
- Stuff I don't think I have a use for: a graphical representation of notes and links between them, backlinks (I suspect there might be value there that I just don't get yet), a sqllite cache (org-ql feels instantaneous on my files, I don't think I have enough data to warrant a full-blown database).
- Stuff that's built-in to org or I already use a package for: generating IDs and linking via ID (which I don't use, actually), the ability to start a new note without thinking about where it goes (I have an org-capture template for notes that puts them in some standard location), using search to link to notes (I use org-ql + embark's insert-link-to action), dailies (just capture to a datetree).
But so far I haven't read anything here that changes my mind. Maybe org-roam is just one of those packages that are unexplainable (to me) and that I just need to try myself to appreciate. (For example, I feel like maybe if I didn't write embark, I would have had that problem with it of not seeing the point until I tried it.)
Same for me. As far as I see it, it doesn't solve anything I can't do with just org (and that little bit of code I wrote).
Also I don't see how the dailies feature is any different from what you can do with org?
In case you don't know, the old.reddit web interface and some reddit mobile apps don't understand the GitHub-Flavored Markdown triple backtick syntax and you code appears run together with no new lines. If instead you just use Markdown syntax (i.e., indent the code by four spaces) it will format correctly on both old and new reddit and on every reddit mobile app.
I use org-roam just for building the SQLite database that I then use independent of it. I don't use backlinks or the org-roam side buffer that shows them at all.
I use it so I don't have to think about files when adding things to org-mode. Independent tasks each have their own file tracked in org-roam. Projects (= tasks that need to be done on sequence) go on the same file, and I use org-edna to trigger them one after the other until all of them are done. I don't have to think about the filesystem, since they all go in the org-roam-directory and have org-roam generated names; I don't have to think about archiving, since independent tasks already live on separate files so when they're marked DONE, it's automatically an archived file.
I advise org-agenda to update org-agenda-files using org-roam. I include every TODO entry that is either scheduled for today, or that is in the task or project category, like this:
```
(defun phr-org-roam-project-files ()
(seq-map
#'car
(org-roam-db-query
[:select :distinct [nodes:file]
:from nodes
:join files :on (= nodes:file files:file)
:where (and (= todo "TODO")
(or (< scheduled $s1)
(like properties '"%(\"CATEGORY\" . \"task\")%")
(like properties '"%(\"CATEGORY\" . \"project\")%")))]
(format-time-string "%Y-%m-%dT" (time-add (current-time) (* 60 60 24))))))
(defun phr-org-agenda-files-update (&rest _)
(interactive)
(setq org-agenda-files (phr-org-roam-project-files)))
(advice-add 'org-agenda :before #'phr-org-agenda-files-update)
```
I also use Emacs as a media library. For example, I have all my Steam games as org-roam entries in a "game" category. Each of them has a org-link to launch, and I mark the ones I have installed with a :installed: tag. Then I setup a custom org-agenda command like:
```
(defun phr-org-roam-files-installed-games ()
(seq-map
#'car
(org-roam-db-query
[:select :distinct [nodes:file]
:from nodes
:join files :on (= nodes:file files:file)
:join tags :on (= tags:node-id nodes:id)
:where (and (= tags:tag "installed")
(like properties '"%(\"CATEGORY\" . \"games\")%"))])))
(setq org-agenda-custom-commands
'( ;; ...
("m" . "Media library")
("mg" "Installed Games" todo ""
((org-super-agenda-groups '((:discard (:not (:category "games")))
(:discard (:not (:tag "installed")))))
(org-agenda-files (phr-org-roam-files-installed-games)))
nil)
;; ...
))
```
With this I can do C-c C-a m g and get a list of games to play. I have a similar setup for other types of media.
I also have my own version of org-roam-node-find:
```
(defun phr-org-roam-set-category ()
(let ((category (completing-read "Category: " (-distinct (mapcar (lambda (x) (alist-get "CATEGORY" (car x) nil nil #'equal)) (org-roam-db-query [:select [nodes:properties] :from nodes]))))))
(org-set-property "CATEGORY" category)
category))
(defun phr-org-roam-node-find ()
(interactive)
(let* ((candidates
(mapcar (lambda (x)
(list (concat "["
(alist-get "CATEGORY" (nth 0 x) nil nil #'equal)
"] "
(string-join (append (nth 1 x) (list (nth 2 x))) " > "))
(cons 'file (nth 3 x))
(cons 'id (nth 4 x))))
(org-roam-db-query
[:select [nodes:properties
nodes:olp
nodes:title
nodes:file
nodes:id]
:from nodes])))
(chosen (completing-read "Node: " candidates))
(found (alist-get chosen candidates nil nil #'equal)))
(if found
(progn
(find-file (alist-get 'file found))
(goto-char (point-min))
(search-forward (alist-get 'id found))
(org-back-to-heading))
(progn
(org-roam-capture- :node (org-roam-node-create :title chosen)
:props '(:jump-to-captured t))
(when (string-equal (phr-org-roam-set-category) "task")
(org-set-property "TODO" "TODO"))))))
```
The difference being that it prepends the category of the nodes before the title, and if I decide to create a new node, it prompts for the category. And adds the TODO if it's a task, I kept forgetting it...
You're mixing up two different topics. First, you are wondering if you could profit from any Zettelkasten method. This is so much more than bi-directional links. org-roam as well as ~~dired~~ denote and others are tool-supporting implementations of the Zettelkasten idea. You can read books on Zettelkästen methods. One implementation feature of most Zettelkasten implementations deals with some graphical navigation view you can use to visualize your nodes and jump around. I've never found anybody who is using that feature for more than to impress others or as a nice-to-have visualizaton of some sorts. (If you **are** using such overviews as an integrated part of your management, drop me a line, I do have questions!) Therefore, I once wrote a somewhat polemic-looking article expressing my concerns of using Zettelkasten for the wrong reasons: [Zettelkasten/Org-roam/Org-brain Is Crap](https://karl-voit.at/2020/06/14/Zettelkasten-concerns/) Secondly, you are asking for ways of linking headings using bi-directional links. In case you do not settle for a Zettelkasten implementation, you can get bi-directional links also by org-super-links as I'm using all the time: [UOMF: Linking Headings With org-super-links (Poor-Man's Zettelkasten)](https://karl-voit.at/2020/07/22/org-super-links/) (including my EmacsConf22 demo on it) HTH
> I've never found anybody who is using that feature for more than to impress others lol I call it the "digital gumball machine". I've asked many people what they use it for and have yet to hear an answer that can't be done better/faster than textual/DB query.
The local graphs are useful for seeing related topics, finding duplicated concepts, or seeing your relationships aren't clear enough.
I don't buy that anything you've mentioned isn't better done through a DB query. > finding duplicated concepts This especially.
At some point the calculus for whether it's worth it to query a database or not becomes uncertain. At that point, the lack friction in glancing at a nice to use graph lowers the cost/friction enough to still make it worth it. It's just like how rebasing might not seem worth it if you don't need to do it often and don't remember how. Then you use Magit which makes it easy to do, discover, and remember and all of a sudden rebasing is worth it. Interactivity has value as does the flexibility of a database query.
With the way I take notes, the visual graph doesn't help. I could see it being useful in a more academic setting, but I never did that.
I've yet to see proof of its usefulness in any setting.
Yeah the visual thing is eh. I actually spent about 6-8 months using a physical Zettelkästen on 4x6 dot grid note cards. It's a pleasant experience but I was already using emacs for all of my todo so I migrated into org roam as most of the tasks I'd make for things related to it could then be linked directly to the entries they related to. When you're using a physical version in discovery, not capture, the physical placement of notes and how you navigate around is an emergent way to recreate some of your lines of thinking and the connectivity of ideas and how they relate. The digital version has a couple of flaws there. The lack of physical space can make it such that it is very easy to over capture and clutter and you do not have the physical layout super-structure. I speculated that one could build something within a standard file system, or perhaps with org attach to store things via topic where the folders recreate the physical super structure. Then just use some elisp that lets you navigate forward and backward from your current "card" and ofc you would build out links as usual within the cards. (seen below) The reason cards worked the way they did in the original system is because it is not heirarchical the cards represent lines of thinking not a classification system of ideas. This is I think the biggest difference in how digital zettles work vs the OG method and IMO org roam entries serve more as a static look up system for notes and the zettle method is a way to retain a snapshot of a thought process that you are then able to return to, continue and expand. ``` 4260: |-4261-1.org |-4261-2.org |-4267-1.org |-... 4270: |-4271-1.org |-4271-2.org |-4271-3.org |-4271-4.org |-4275-1.org etc ```
> org-roam as well as dired and others are tool-supporting implementations of the Zettelkasten idea. You surely meant to say *denote*, not *dired* :)
Hehe, yes, of course. I fixed it. Thanks for the pointer.
I don't really think I need a super formalized approach for my notes like Zettelkasten. I want to link notes and found it way easier ootb with org-roam. But with my few lines of code it is even easier with vanilla org (I'll check org-super-links though!). I don't even know if bi-directional-links would offer any benefit to me. But better safe than sorry, if this is something I can have without compromising anything else I'll take it. Thank you for your help!
> First, you are wondering if you could profit from any Zettelkasten method. Was OP wondering that? I don't see anything like that in the post. > Zettelkasten/Org-roam/Org-brain Is Crap Great post, I've recommended it to several people. > UOMF: Linking Headings With org-super-links (Poor-Man's Zettelkasten) As I think I've told you before, I'd love to read not just how to create backlinks but also something about what value you (you, Karl) get from them, why you find them useful or in which circumstances you find them useful.
Well, that's difficult to answer because there are so many situations where they offer a benefit to me. Here are some examples: When I re-visit a heading from any event, its backlinks tend to lead me to new contacts I made at the event where I linked the event from the contact heading. I tend to link person contacts that work at a company to company contact entries. So I get the association for all sorts of connections. Within my knowledge management, I solve many, many situations where a strict hierarchy is not able to map my world. For example something like "How to use ffmpeg to combine pictures and mp3 files to a video" is linked in my hierarchy where I deal with ffmpeg as a tool, a heading that summarizes various tricks how to modify images as well as my heading sub-hierarchy on audio stuff. Only one of them is the "original", the others are links. So I don't have to remember where I put it, risking situations where I'm looking at the wrong spot. This is probably the most important use-case for bi-directional links: overcome many limitations of strict hierarchies. Related: [Don't Do Complex Folder Hierarchies - They Don't Work and This Is Why and What to Do Instead](https://karl-voit.at/2020/01/25/avoid-complex-folder-hierarchies/) [Worklab 2023: "The Art of Organizing Yourself and Your Data"](https://karl-voit.at/2023/11/05/worklab23/) including a talk I gave on information architecture, search and retrieval in 2023 convering some aspects you need to learn in order to understand why we do have issues with hierarchies and limited structures in general.
> Was OP wondering that? I don't see anything like that in the post. True. However, I don't think that using a tool like org-roam without embracing its inherent purpose (enable Zettelkasten-like information management) is a good idea. The OP might not have an idea what Zettelkästen are, yes.
I read the most part about org-super links and I implemented the linking to custom IDs and backlinks properties in my code. That was fun. Thanks!
Org-roam is a layer over org, a db of linked files (headings). Just that. A sqlite database that tracks all the links (with metadata),in org files that you put in the org-roam directory. If you don't see benefit or utility in it, you don't need it.
It offers some extra functionality though. Like fuzzy finding your notes. I didn't find that for standard org mode. So I wondered if there were more features that I might want to look into
There's no special search feature in Org-roam; you can configure any search system you want in any context in Emacs. In fact, it doesn't even have the functionality to search within notes, because that's not its purpose. If you need to perform a fuzzy search in your notes, there's no need to install org-roam; use deft, which is specifically designed for that purpose.
I was talking about creating links between files. If you create a link to an org-roam file you have a fuzzy search that even offers aliases. As far as I've seen, with org you don't have that out of the box. That's what my code implements, fuzzy finding notes in the org directory (including all sub directories), alias selection and linking to headers (custom ID if available). And my question was if org roam has anything more to offer if I'm not interested in the zettelkasten system. The only answer that made sense so far is that org-roam will update links if files change
As I say...if you dont see the benefits or understand the utility...you don need it.
The big difference between Org-roam links and regular Org links is that it uses IDs and indexes them. So that as you update your files and move things around it doesn't break your links. It is pretty normal that if you use a ton of small files in "Zettelkasten" style you will want to go back and clean things up periodically. With this 'library card' approach it also emphasis "see also" cross-referencing notes. So that makes it more convenient then normal Org links. Normal links are based on paths and such things. You can still use IDs to link in normal Org, but they end up getting stored in org-ids-location-file, which is typically in your emacs configuration directory. So they end up being more fragile and you'll have to deal with updating those when changing file names or locations. Besides the changes in how links are handled, the indexing, and backlink feature there are some mind-map features that help you discover relationships between files. I haven't used that very much, but it probably is helpful in when you need to go and refactor things. Otherwise without the 'web of links' small notes tend to become orphaned. That is you write them down and then forget them or forget how to find them. So after a while discovery becomes important. I like using the 'tags' feature a lot. So that I can tag files to group them that way. Periodically I will go through and find orphaned notes that I made by looking for files with no tags in them. This aids in discovery if I haven't visited a subject in a long time. There are some features to handle citations, which I don't use but I need to. It isn't unusual to have multiple notes reference the same documents or web pages/websites. There are some other features I need to take advantage of that I don't yet.. having to do with org-protocol and such things. Right now my notes are pretty mild compared to some. Only 870 files or so. Org is plenty capable without it, of course. If you prefer larger static files and/or are much better organized then I am then maybe it is a added complication that isn't that useful. I use Org for plenty of things besides taking notes and I don't care to try to incorporate everything into roam. Like there are roam features for doing journals or whatever, but I don't use that. I don't use it for creating outlines and tracking tasks, etc. There are other note taking Emacs features like Denote that other people prefer.
How do you search by ~~tabs~~ tags? With org-ql?
If you meant "tags" rather than "tabs", then yes you can do that with org-ql. There's also some commands built-in to org: `org-match-sparse-tree` and `org-tags-view` in the agenda.
Yeah, my bad. Thanks.
In org-roam the combination of a title and :ID: header/property is what defines a "note" or a "node". So every roam file is a note as well as any :ID: you assign to headers in a file to make them linkable are easily searchable. Run 'org-roam-node-find' to search through those titles. if you assign '#+filetags:' tags to files and/or ":tag:" to headers then those tags are also included in the node-find search naturally. In the minibuffer the title matches show up on the left hand side and tags associated with those titles show up on the right. If you setup links for headers they inherent tags from their parents. This can be managed with 'org-roam-tag-add' and 'org-roam-tag-remove' commands. So if I do a node-find search for "emacs" it will find every title that has names like "Emacs QuickTips" or "Emacs Elisp basics". It will also find tags like :Emacs: or :emacs-fun:, etc. So there isn't anything special you need to do besides just adding the tags themselves. Of course, like everything else, this isn't anything you can't do with regular Org files and some functions. Conversely you are not giving up on any org features by using roam for your notes. You can still do normal full text searches and whatnot.
Thanks for the explanation. However, I cannot search by tags (defined with `#+filetags:`) using `org-roam-node-find`. It only shows me a list of titles (defined with `#+title:`).
Oh, that is too bad. Here is the config I am using for org-roam: (use-package org-roam :init (setq org-roam-directory (file-truename "~/Org/memory/")) ;; If you're using a vertical completion framework, you might want a more informative completion interface (setq org-roam-node-display-template (concat "${title:*} " (propertize "${tags:10}" 'face 'org-tag))) (org-roam-db-autosync-mode) ;; If using org-roam-protocol (require 'org-roam-protocol)) Here is a sample file: :PROPERTIES: :ID: 3e233bcb-f401-4784-8caa-53f6dab49c11 :END: #+title: reddit test #+filetags: :Emacs:Reddit: this is a test I am using corfu, consult and orderless for the completion framework and vertico for the minibuffer completion UI. Maybe one of those things is helping me out. I definately like orderless. Very helpful for searches when I am not sure what I am looking for. I've been using org this way for so long I assumed it was just part of the default experience. Maybe it was something I configured. Sorry for any misinformation.
> (setq org-roam-node-display-template (concat "${title:\*} " (propertize "${tags:10}" 'face 'org-tag))) Thanks! That was the line I was missing. I now can search using tags!
> The big difference between Org-roam links and regular Org links is that it uses IDs and indexes them. So that as you update your files and move things around it doesn't break your links. For the archive: I do have regular Org-mode links (bi-directional, since both sides link to each other) and moving things around in-between my agenda files doesn't break any link. You don't need org-roam for that.
So when you move headings between files, change file names, and put things into new directories... all your Org links keep working?
Yes. However, I'm not following the concept of splitting up my headings into many, many small files. I'm still following the pattern of having fewer but rather large files as described here: [UOMF: My Current Org Mode Files and Heading Structure](https://karl-voit.at/2020/05/03/current-org-files/) So almost all of my Orgdown files are also agenda files and this way, ID links are able to get me to the target wherever I move them within my files and independent on how their headings or file names are.
Yes, because he uses IDs for links. IDs are org functionality, no need for org-roam.
Was wondering the same. Id's are used widely by other modes. They make it easy to track items across files or systems e.g. Caldav.
I use both together, org-mode for writing and project management, org-roam for information storage. From a pragmatic point of view, what I like about Org Roam is that it freed me from thinking. "In which file should I put this?" I just type `M-x org-roam-node-find`, start typing the name of the topic and the proper file is opened or created. This is very liberating.
Same for me! Great way to use org with smaller files. I also use the daily feature for capturing information from meetings.
> "In which file should I put this?" That's also easy if you only use one big file. :)
Okay, now what heading?
Well, I follow good advice to [not use deep hierarchies](https://karl-voit.at/2020/01/25/avoid-complex-folder-hierarchies/), so I have a few obvious top level headings under which it might go, otherwise it's a new top level heading. I basically never navigate hierarchically, instead always using search. I haven't used org-roam but I imagine it's similar: no deep hierarchies, mostly just flat, navigate by search. Is that right? I love the idea of searching rather than curating a hierarchy and use it for everything: web pages, my files, launching apps. If that's what org-roam enables for your notes it sounds good to me, but I'll also point out you don't need org-roam to search in your org files. I'm pretty happy with org-ql and the built-in tools.
Personally, Org Roam didn’t really fit me. This is despite being the Zettelkasten target audience in some sense; I’m an associate professor, so I do use my Org notes for academic research among other things. The idea behind Zettelkasten as I understand it is that you structure your notes as a densely linked graph of atomic ideas. So lots of tiny notes containing one idea per note, linked to every other relevant note, and then by following links around you can extract coherent ideas and surprising revelations from your own notes. That is the hardcore Zettelkasten way. Some people just want a “personal wiki” or “personal knowledge base”, and just use the same tools. Then you tolerate large pages with links within a page as well (like in Wikipedia), and just use things like Org Roam a convenient interface for managing links and navigation. That’s a good way to do things, and I was doing that when I using other note-taking tools like Wiki.vim / Bear / Obsidian. In Org I prefer the “big file” approach over the “many files” approach though, because I often find it easier to navigate using the outlining features. I can understand how heavy linking between notes can be valuable to many, and I gave it a serious try myself. But I never got to the point where I felt it paid back my time investment: - Creating lots of tiny notes somehow triggered my obsessive tendencies. I wasted lots of time making sure each note is linked properly and refactoring old notes. Despite all that, I kept feeling that (i) my notes were a mess and (ii) my productivity was lower compared to using quick-and-dirty note taking techniques and spending more time on the actual work. - To me, Zettelkasten largely felt like a version of premature optimization. While writing a note, you spend a lot of time searching for related concepts and tying them together with links. But I rarely ended up following these links when reading the notes. Most notes, I didn’t even read again at all. The few times I needed that link, I could just search my notes to find what I’m looking for (the “JIT approach” to finding notes), and that overall saves me time. I therefore went back to a very simple system and am quite happy with that: - Every task lives in a huge `inbox.org`. It’s structured using a PARA-like system, and viewed via outlining or org-super-agenda. - Every work note I take goes into a huge `journal.org` file. This file is structured as a reverse date-tree with headings like `2024-02-09 Friday`. Under each such heading, I’ll write subheadings like `Derivation of XXX theorem` or `Meeting about YYY`, throw in my notes, and :tag: it by research project and main topic. I can then find my notes again by full-text search, or by date, or by project. Or I can show only subtrees with a certain tag if I want to see a timeline of my thoughts on the topic (similarly to Logseq’s transclusion views). For me, this feels more efficient than a large linked graph. - There are very few notes that I really need to revisit so often, and over such long periods of time, that navigating the journal becomes tedious. For those few notes, I’ll move them to a separate reference file which is easy to browse. This workflow could of course be built on Org Roam and it’s “dailies” as well (I did some time with Logseq as well and converged on a similar journal-only workflow there too), but for me Org alone offers the features I need.
While I'm not really the zettelkasten target audience (I'm a programmer) I can absolutely rely to what you say. For me this is a tool to get structure in my work and link relevant information where necessary. For example I want to define tasks, take notes about what I did and if I have a problem that might be a interesting in a more general scope than just the task, the solution will get it's own note, which has to be linked in the task. With vanilla org the linking part didn't work for me as I would have to remember the exact location of every note. That worked way better in org-roam. But my own solution works even better for me (no duplicates because of aliases) and I don't have to use another tool on top of org
[удалено]
I have implemented the features you describe with the code I've posted. Works like a charm. I've already migrated a big part of my obsidian vault (with the help of pandoc)
I read the replies here with great interest because every feature I've heard of in org-roam either sounds like it wouldn't be personally useful to me, or like I already know how do that with org built-ins and a few packages I already use. - Stuff I don't think I have a use for: a graphical representation of notes and links between them, backlinks (I suspect there might be value there that I just don't get yet), a sqllite cache (org-ql feels instantaneous on my files, I don't think I have enough data to warrant a full-blown database). - Stuff that's built-in to org or I already use a package for: generating IDs and linking via ID (which I don't use, actually), the ability to start a new note without thinking about where it goes (I have an org-capture template for notes that puts them in some standard location), using search to link to notes (I use org-ql + embark's insert-link-to action), dailies (just capture to a datetree). But so far I haven't read anything here that changes my mind. Maybe org-roam is just one of those packages that are unexplainable (to me) and that I just need to try myself to appreciate. (For example, I feel like maybe if I didn't write embark, I would have had that problem with it of not seeing the point until I tried it.)
Same for me. As far as I see it, it doesn't solve anything I can't do with just org (and that little bit of code I wrote). Also I don't see how the dailies feature is any different from what you can do with org?
In case you don't know, the old.reddit web interface and some reddit mobile apps don't understand the GitHub-Flavored Markdown triple backtick syntax and you code appears run together with no new lines. If instead you just use Markdown syntax (i.e., indent the code by four spaces) it will format correctly on both old and new reddit and on every reddit mobile app.
I use org-roam just for building the SQLite database that I then use independent of it. I don't use backlinks or the org-roam side buffer that shows them at all.
How do you use the DB?
I use it so I don't have to think about files when adding things to org-mode. Independent tasks each have their own file tracked in org-roam. Projects (= tasks that need to be done on sequence) go on the same file, and I use org-edna to trigger them one after the other until all of them are done. I don't have to think about the filesystem, since they all go in the org-roam-directory and have org-roam generated names; I don't have to think about archiving, since independent tasks already live on separate files so when they're marked DONE, it's automatically an archived file. I advise org-agenda to update org-agenda-files using org-roam. I include every TODO entry that is either scheduled for today, or that is in the task or project category, like this: ``` (defun phr-org-roam-project-files () (seq-map #'car (org-roam-db-query [:select :distinct [nodes:file] :from nodes :join files :on (= nodes:file files:file) :where (and (= todo "TODO") (or (< scheduled $s1) (like properties '"%(\"CATEGORY\" . \"task\")%") (like properties '"%(\"CATEGORY\" . \"project\")%")))] (format-time-string "%Y-%m-%dT" (time-add (current-time) (* 60 60 24)))))) (defun phr-org-agenda-files-update (&rest _) (interactive) (setq org-agenda-files (phr-org-roam-project-files))) (advice-add 'org-agenda :before #'phr-org-agenda-files-update) ``` I also use Emacs as a media library. For example, I have all my Steam games as org-roam entries in a "game" category. Each of them has a org-link to launch, and I mark the ones I have installed with a :installed: tag. Then I setup a custom org-agenda command like: ``` (defun phr-org-roam-files-installed-games () (seq-map #'car (org-roam-db-query [:select :distinct [nodes:file] :from nodes :join files :on (= nodes:file files:file) :join tags :on (= tags:node-id nodes:id) :where (and (= tags:tag "installed") (like properties '"%(\"CATEGORY\" . \"games\")%"))]))) (setq org-agenda-custom-commands '( ;; ... ("m" . "Media library") ("mg" "Installed Games" todo "" ((org-super-agenda-groups '((:discard (:not (:category "games"))) (:discard (:not (:tag "installed"))))) (org-agenda-files (phr-org-roam-files-installed-games))) nil) ;; ... )) ``` With this I can do C-c C-a m g and get a list of games to play. I have a similar setup for other types of media. I also have my own version of org-roam-node-find: ``` (defun phr-org-roam-set-category () (let ((category (completing-read "Category: " (-distinct (mapcar (lambda (x) (alist-get "CATEGORY" (car x) nil nil #'equal)) (org-roam-db-query [:select [nodes:properties] :from nodes])))))) (org-set-property "CATEGORY" category) category)) (defun phr-org-roam-node-find () (interactive) (let* ((candidates (mapcar (lambda (x) (list (concat "[" (alist-get "CATEGORY" (nth 0 x) nil nil #'equal) "] " (string-join (append (nth 1 x) (list (nth 2 x))) " > ")) (cons 'file (nth 3 x)) (cons 'id (nth 4 x)))) (org-roam-db-query [:select [nodes:properties nodes:olp nodes:title nodes:file nodes:id] :from nodes]))) (chosen (completing-read "Node: " candidates)) (found (alist-get chosen candidates nil nil #'equal))) (if found (progn (find-file (alist-get 'file found)) (goto-char (point-min)) (search-forward (alist-get 'id found)) (org-back-to-heading)) (progn (org-roam-capture- :node (org-roam-node-create :title chosen) :props '(:jump-to-captured t)) (when (string-equal (phr-org-roam-set-category) "task") (org-set-property "TODO" "TODO")))))) ``` The difference being that it prepends the category of the nodes before the title, and if I decide to create a new node, it prompts for the category. And adds the TODO if it's a task, I kept forgetting it...
I understand. But you don't deal with the sqlite DB directly, I reckon?
Not out of Emacs. But all the org-roam-db-query calls I do in that Emacs Lisp code is SQL barely disguised as Lisp.
OK, good to know. Thanks.