The title*headline style links will no longer work. roam links will now simply look like:
[[roam:node_title]]
These should either resolve to the first node in the database, or bring up a list of nodes that match. We can also start going fancier: [[roam-tag:foo]] may show all roam nodes with tag foo, for example.
Hello,
I’m an org-user just about to start with org-roam…any hint how to start to make migration to V2 easier?
I’ve been trying to decide between “normal” org-mode note taking with a few files vs org-roam with multiple files.
If I understand this major re-design correctly, since a headline would now be the lowest node, does it mean org-roam will work with the few file setups as well? Or will it still require the multiple files?
Kudos to Jethro! This new version of org-roam definitely will be smoother in terms of linking files. I personally don’t like the file paths due to the renaming and sometimes dealing with breaking paths. Using ID’s seems more natural.
I just want to suggest an idea to the implementation. Org-id creates by default UUID’s which are 100% unique even across machines. However, they aren’t human-readable, and frankly I think most people won’t need something that strong to link files.
One solution is to add the timestamp as ID. This way the ID is unique for your personal use, and it is very natural. I had this idea to implement footnotes instead of inline links (How to create cleaner structured notes?). Other software like “The Archive” uses the same idea though.
Thanks.
Org ID actually allows for time stamps as IDs, it’s just not the default. I’m on mobile right now so I can’t give a clear instruction on how to set it up. But personally I’ve been using time stamps with Org roam for quite some time now without issues. Just thought to mention it, since it’s already supported.
In my workflow I have org-roam-prefer-id-links set it to t and my org capture template sets in the top part of the file the ID with the timestamp.
I’m wondering how it’s your workflow @Gustav?
My idea, to be perfectly clear, is towards to allow the user could choose between uuids or timestamps to links their nodes.
Yes and no, there should still be some slow-down (for now) if your Org files are ridiculously huge. I’m not going to be prescriptive here, but headline level nodes have additional functionality that Org file-level nodes do not:
These are now being cached along with the nodes, which will form the basis of a super-fast (but functionally limited) org-roam-agenda command.
I leave this up to personal taste, but to do this you can simply set (setq org-id-method 'ts).
Org-roam doesn’t care how the IDs are generated, you can type your own, if you wanted.
A very useful feature: Being able to add todo’s to roam notes, and make it appears in some agenda without having to either add/remove each files manualy nor all of them (too) numerous notes to the org-agenda-files.
I’m hoping to be able to save the org-roam-agenda buffer to a “todo” org file that could be then added to the org-agenda-files and be used as my other agenda files, exported to .ics and synchronized to an orgzly directory on my phone…
Anyway, great, thank you Jethro!
I will just share what I have done, and invite others to comment.
If you are just starting out with a blank slate, I think it would be best to
Start creating links with an ID generated with using org-id.
Set org-roam-prefer-id-links to t, then org-roam-insert will use the ID for links automatically.
(optionally) Upgrade your Org Mode to 9.4
Optional if you are thinking of using files as the base unit of notes, rather than headlines. With this version, you can have properties at the file level on top of the file before the first headline (in a property drawer including ID – see the image below for what I have done).
(limitation) Export does not seem to be able to resolve my IDs – and fails to export. I do not know exactly why this is the case – I do not use export, so no issue for me. But this affects Org-roam-server’s preview feature (not the graph rendering itself, which is working for me beautifully)
The current version of Org-roam takes the :title: property in the top-level (level 0) property drawer, so there should be no issue using Org-roam.
I have just done this for a major part of my Org-roam directory myself. It is working great so far.
As Jethro suggests in a comment above, Org-roam does not, and v2 will not care how the IDs are generated; I am using my own custom timestamp format that I like as the file ID. I don’t link to headlines, but should I do, I would use Or-id’s timestamps with the (setq org-id-method 'ts) option.
I’m all for easing development work and improving the code basis but am a bit scared about loosing work.
@laotang
I do not think we can expect prescriptive advice on this by anyone, so I just share how I think about it.
tl;dr: I personally see no reason to hurry to migrate existing notes.
You will lose nothing
You can choose to continue to use the v1. You have a choice when/if you want to move to v2
We can reasonably expect that there will be some migration tools to v2
This will be either by Jethro (I believe he himself would need to migrate part of his notes) or collectively by the community (you can see some foundational work done from a couple of posts above in this thread)
The reason I could do what I shared above is that I have just started using Org-roam for work, which to me is in a dedicated sub-folder. This was a fresh start.
My personal sub-folder is full of markdown files and org files using my Md-roam and Org-roam v1. For this, I will wait for the release of v2, and then see the best course of migration (best for my particular setup).
Do I understand correctly that every headline will now have three lines under it of the form
:PROPERTIES:
:ID: 427d5824-b09c-448e-b5db-5aa9f7a3fe4b
:END:
I am currently able to use the Tab key to collapse any such group of 3 lines to a single line (the first). But I don’t know how to hide it completely. I suspect I’m not alone in that I’ll want to. Is there a way?
But I don’t know how to hide it completely.
It was hacked by tweaking overlay code by @Kinney. It might have
performance issues when you have many headlines.
You can find more story here in Chinese.
(defun org-hide-properties ()
"Hide org headline's properties using overlay."
(save-excursion
(goto-char (point-min))
(while (re-search-forward
"^ *:PROPERTIES:\n\\( *:.+?:.*\n\\)+ *:END:\n" nil t)
(overlay-put (make-overlay
(match-beginning 0) (match-end 0))
'display ""))))
(add-hook 'org-mode-hook #'org-hide-properties)
Yes, I also find that property drawers, etc. clutter org-* files, greatly reducing readability. This is especially unergonomic when rapidly scanning through a large volume of notes – the most common use case if the Zettelkasten idea is really working.
So, some way of completely hiding org-roam meta information seems very important.
I might be on the minority side, and prefer to have the top-level drawer open when I visit an org file, but setting this variable get org files to open with drawers folded.
(org-startup-folded nil) ;; this is from my customizing variable
EDIT: sorry, you meant the headlines: the variable seems to work for headlines. Don’t feel it is distracting to me.
With this face, I don’t find it distracting – my personal taste.
I would not hide the property drawers completely (I have useful information that I want to see in it).
org-roam-directory. Right: an org file opened.
I use a simple custom function for Dired where I can go up and down, and open the file as my cursor move along the dired
A node is any headline or top level file with an ID.
That’s the way to go, I’m fully on-board with this one.
- todo keyword
- priority
- scheduled
- deadline
These are now being cached along with the nodes, which will form the basis of a super-fast (but functionally limited)
org-roam-agendacommand.
This is fantastic. Could we think about also caching the first inactive timestamp under the headline? I think this is the “almost official standard” way of defining headline creation dates.
If these were cached, we could set things up to click on a timestamp and go to a view of all the headlines for the day. This would close the loop between a time-based view and a knowledge-graph view of your notes.
Org-agenda has this feature (sort of) but it would be much more useful in org-roam. Roam Research is a good model of how it would work.
UPDATE: For clarity, this is what I’m talking about:
* My headline
[2021-01-29 Fri 19:24]
My notes here.
This would bring org-roam much closer to org-brain. I think the approach makes sense. One advantage of org-brain was the ability to access these nodes/headlines with the hierarchy using brain: links and I was missing this with org-roam for the longer notes with multiple headings.
I think it would be useful to also consider tools to handle duplicate org-id links.
How will opening files work then in the future? All #+title: and headlines stored in the database and org-roam-find-file presents them all?
#+roam_tags on a “per file” base or “per headline”?
Thanks a lot for the reply!
You are right and I might continue to use v1 for a while. For me org-roam is feature-complete (but then again, @jethro mentioned something about a mini-agenda :).
That is probably true. Even in this thread some people already generously offered their help.
Just in case I want to start using UUID, what do I have to include in my init-file? I noticed that I have
(require 'org-id)
(setq org-roam-prefer-id-links t)
in there, but it does not seem to have any impact.