You might like to open a new thread, rather than trying here, but just quickly, make sure that your config really has no impact:
org-toggle-link-display (see the image below)org-id-copy, and then in a different note, use org-roam-insert to insert a link.org-roam-find-node presents all nodes in the database. The nodes have their file and point in buffer stored in the database, so it’s just finding the file and going to point.
Thanks. You are right, this should probably go into a different thread. I actually had this working months ago and the missing line was:
(setq org-id-link-to-org-use-id t)
(just in case someone was wondering)
Org-ids, however, are somehow not working properly with my window management (they always open in current-window, not in other-window) - but this truly belongs somewhere else.
I can see how a visible :PROPERTIES: is not too distracting when the notes are long form.
But for short notes, a :PROPERTIES: below every headline chews up a large fraction of vertical screen space, even when collapsed. Most of my current org-mode notes are Zettelkasten-sized – only a few lines. Converted to v2 org-roam, about a fifth of what I’d see on my screen would be non-information.
It’s true that the contents of :PROPERTIES: drawers are important, so once in a while, I’d like to look in them. But most of the time, not.
So it seems better to hide them out of the way, with a keyboard shortcut that toggles them on and off.
As @jethro said, title*headline style links will break, so don’t use them 
My personal advice, use id links, e.g. [[id:XXXXX][title]]. Just like @nobiot described it. Since the most breaking change is db structure, don’t invest too much into scripts around current schemes Everything else should be transparent and org-roam will help with migration.
I am building agenda files list on the fly and it works ridiculously fast.
This thread grown quite a bit and I’m late to the party and I’m not sure where to start.
Do we have updated instructions somewhere for recommended shapes for org-roam-capture-templates, org-roam-capture-ref-templates, and org-roam-dailies-capture-templates so they work nicely with v2?
Like for example: I see you have file level properties drawer and it seems to be the very first item in the file. Is that right?
As I understand, those who get Org-roam from MELPA automatically start using v2, right?
How would the re-design affect org-roam-server? Does it mean that the links to headlines would also be displayed in the graph?
How can we (non-maintainers) help? Do you think getting Org-roam from v2 branch directly would help flushing out the bugs early, or it’s expected that many things would break there and staying pointed to master is safer?
I am building agenda files list on the fly and it works ridiculously fast.
I haven’t read it, but let me ask you before diving into it
Can’t you just have org-agenda-files to point to a file that contains folders and files that need to appear in Agenda?
Like mine set to (setq org-agenda-files "~/org/.agenda-files") and the content of that file is the following:
index.org
./
./daily/
./web/
./read-later/
index.org the first there because (I think) Spacemacs detects the first item in the list and opens that file when you open Org layout/persp
That way any file added to any of the folders would be picked up by agenda automatically. But maybe I’m missing something here?
update: Ah… never mind. You explain the reasons in the first paragraph. Great, I’ll probably try to follow. Sorry for the noise.
This looks great! Sounds like I would be able to move back to my original structure of documents where I only create ID’s for those headings that need to be cross-linked.
One question: what would be the syntax for #+roam_alias: and #+roam_key: entries? Do we just put them in the property drawer like so?
* books to read
** How to take smart notes---Sönke Ahrens
:PROPERTIES:
:roam_key: cite:Ahrens2017
:roam_alias: "how to take smart notes"
:END:
*** notes should be atomic
May I ask what that custom function is?
apols - sorry I should have put two and two together
No worries. Not directly related to Org-roam V2, but I seem to have managed to have a function that opens Dired on the side. I’ll update the other thread with the function.
I’m not too familiar with Roam links, since I’ve always used ID links for portability. I also use ID links for files (when you execute org-store-link at the top level in a file, it creates a PROPERTIES drawer at the top of the file with an ID) for maximum portability.
If you’re moving to an ID-centric linking method now, why keep the roam link style around at all? And how will roam links work now? Will you have a cache mapping all node titles to their ID’s? It seems pointless to me when ID links already exist; furthermore, if someone stops using Org Roam, ID links will still work perfectly, which isn’t the case for Roam links. Do Roam links provide some sort of additional functionality that makes a separate link scheme worthwhile?
It would be even cooler if the org-hide-properties function @cool_ran posted (which I’m happily using) was instead org-toggle-show-properties. Usually I want the properties hidden, but occasionally I do want to see them.
Yes, something like this. I’m thinking of making it ROAM_ALIASES for consistency reasons though.
Will get this right before releasing v2. Might use a self-written version of org-capture.
Yes.
Queries will need to be rewritten to match the new schema. Links to headlines WITH IDS (nodes) can be displayed in the graph.
You’re free to try the V2 branch, which should work with knowledge bases that already use UUIDs. At this time I think the backlinks buffer is much more functional already. But there aren’t any docs yet, so it might be a bit difficult to get started. I’ll send a note here when I think it’s ready for public testing.
I think the primary use case is for delayed creation of notes. So you can have a [[roam:Foo]] link lying around and when you do decide to work on that note, navigate on the link to create the note. However, matching completions will now automatically insert an id link instead. It does become a lot more redundant, since that’s the behaviour of fuzzy links already: [[Foo]] will prompt for a new heading creation.
Yes, this is needed elsewhere too.
I’m thinking of trying it out. My notes have been ID-based already for quite some time. Anything you want to pass along as a caveat or “good to know” before starting to explore?
(Edit: Disregard the question on UUID’s below as we’ve discussed that above in the thread. Sorry for the unnessessary noise!)
Oh, btw - you say “use UUIDs”. Do you mean Org Roam v2 is limited to the UUID implementation in Org ID, or did you mean the regular Org ID functionality, also ID’s based on timestamps or whatever the user chooses?
Major changes:
org-roam-mode is no longer a global minor-mode: it’s the mode used for org-roam buffers. To set up org-roam, use org-roam-setup.
The test function currently used is org-roam-buffer. It should show you a buffer that looks like this, on a node:
Most parts of the buffer should be navigable now: You can jump to node, preview, olp, and unlinked reference. Preview UX is still WIP, but I don’t think it’s essential for v2.
Basically everything else will break: org-roam-bibtex, org-roam-server included.
