My Org Roam Notes Workflow (2021)(hugocisneros.com)
hugocisneros.com
My Org Roam Notes Workflow (2021)
https://hugocisneros.com/blog/my-org-roam-notes-workflow/
19 comments
> a lot of hacks to get exporting to ox-hugo to work
Hello! Please feel free to start a discussion on https://github.com/kaushalmodi/ox-hugo/discussions listing the things you need to tweak in ox-hugo to make it work with Org Roam.
In the past 3 months or so, I have been adding test Org files received from Org Roam users and they seem to be exporting alright.
Tests: https://github.com/kaushalmodi/ox-hugo/tree/main/test/site/c...
I'd welcome more tests there :)
> and improve performance [your config link]
From your config, I see this[1] overriding `org-hugo-link--headline-anchor-maybe`. I am following a general Emacs Lisp convention of naming internal-use functions and variables with `--` in the names. Unfortunately, that advice won't do anything with the latest ox-hugo as I replaced that particular internal function with something else in past few months as I was improving the anchoring scheme to support an Org Roam user with linking headings based on UUID.
At that point I had added this documentation on Anchors[2] in ox-hugo manual. If you set `org-hugo-anchor-functions` to nil, or add a dummy function to it that just returns "", it would do the same thing as you are doing in your advice right now (not tested).
*Note that will basically break the ability to refer to other sub headings by UUID, CUSTOM_ID or any other mechanism.*
---
I'd welcome contributions to ox-hugo code, documentation so that it can help other Org Roam users too. Even if it doesn't make it into the repo, having a discussion related to ox-hugo + Org Roam issues/tips+tricks in the ox-hugo Discussions forum will be useful to others.
Thanks!
---
[1]: https://github.com/alexkehayias/emacs.d/blob/3b546048cc60976...
[2]: https://ox-hugo.scripter.co/doc/anchors/
Hello! Please feel free to start a discussion on https://github.com/kaushalmodi/ox-hugo/discussions listing the things you need to tweak in ox-hugo to make it work with Org Roam.
In the past 3 months or so, I have been adding test Org files received from Org Roam users and they seem to be exporting alright.
Tests: https://github.com/kaushalmodi/ox-hugo/tree/main/test/site/c...
I'd welcome more tests there :)
> and improve performance [your config link]
From your config, I see this[1] overriding `org-hugo-link--headline-anchor-maybe`. I am following a general Emacs Lisp convention of naming internal-use functions and variables with `--` in the names. Unfortunately, that advice won't do anything with the latest ox-hugo as I replaced that particular internal function with something else in past few months as I was improving the anchoring scheme to support an Org Roam user with linking headings based on UUID.
At that point I had added this documentation on Anchors[2] in ox-hugo manual. If you set `org-hugo-anchor-functions` to nil, or add a dummy function to it that just returns "", it would do the same thing as you are doing in your advice right now (not tested).
*Note that will basically break the ability to refer to other sub headings by UUID, CUSTOM_ID or any other mechanism.*
---
I'd welcome contributions to ox-hugo code, documentation so that it can help other Org Roam users too. Even if it doesn't make it into the repo, having a discussion related to ox-hugo + Org Roam issues/tips+tricks in the ox-hugo Discussions forum will be useful to others.
Thanks!
---
[1]: https://github.com/alexkehayias/emacs.d/blob/3b546048cc60976...
[2]: https://ox-hugo.scripter.co/doc/anchors/
There's also the wonderful org-roam-ui which provides a React-based interactive graph of all your nodes for browsing and editing in the browser. The maintainer has just pushed a branch which can be deployed to a public server too.
https://github.com/org-roam/org-roam-ui
https://github.com/org-roam/org-roam-ui
Emacs is a classic desktop, so not a multi-user environment, of course is perfectly capable of networking but in the classic sense, no central point, no "server" etc.
So org-roam notes are personal notes, your own digital information from mail to feeds, passing through financial transactions, attached files, ... there is not use-case for sharing, it's not a wiki. However you can export certain notes to html (eventually selecting them out of org-ql queries) and such html can be a page of a wiki, a page whose source can be in a git repo with push and pull to keep it up to date, but that's not a pre-coocked thing, it's just easy to do since all ingredients are already made.
You can for instance export toward GitIt wiki, or hack DokuWiki mode etc, being inside Emacs makes things far easier.
So org-roam notes are personal notes, your own digital information from mail to feeds, passing through financial transactions, attached files, ... there is not use-case for sharing, it's not a wiki. However you can export certain notes to html (eventually selecting them out of org-ql queries) and such html can be a page of a wiki, a page whose source can be in a git repo with push and pull to keep it up to date, but that's not a pre-coocked thing, it's just easy to do since all ingredients are already made.
You can for instance export toward GitIt wiki, or hack DokuWiki mode etc, being inside Emacs makes things far easier.
Has anyone defined or experienced a good workflow and process for multi-user, selective access/partitioned org-roam notes?
Imagine I’m on a team of five and each of us have information that we consider public, private, company, and company/private. The last two being info that should stay with the company and not with me when I leave, and information that should stay with the company and with me when I leave (perhaps research or best practices we adopted in our use of language Foo or technology Bar [“how we integrate CUDA” or “rules for smooth DB migrations”], where it’s not company proprietary but the company should have continued access.)
I can easily see how I could use org to organize my own information, but if I use it to create a silo of information that only I can access and that, from the company perspective, dies with me when I resign, that feels selfishly sub-optimal.
(Perhaps “public” and “company/private” are the same category in effect, but user1’s private and user2’s private are definitely different. I’d be willing to take any reasonable restriction such as segregation must be on a per-file basis.)
Imagine I’m on a team of five and each of us have information that we consider public, private, company, and company/private. The last two being info that should stay with the company and not with me when I leave, and information that should stay with the company and with me when I leave (perhaps research or best practices we adopted in our use of language Foo or technology Bar [“how we integrate CUDA” or “rules for smooth DB migrations”], where it’s not company proprietary but the company should have continued access.)
I can easily see how I could use org to organize my own information, but if I use it to create a silo of information that only I can access and that, from the company perspective, dies with me when I resign, that feels selfishly sub-optimal.
(Perhaps “public” and “company/private” are the same category in effect, but user1’s private and user2’s private are definitely different. I’d be willing to take any reasonable restriction such as segregation must be on a per-file basis.)
Think multi-user org-roam publishing is what the folk around anagora.org are doing.
https://anagora.org/
https://anagora.org/
As far as I can tell, there's no multi-user features in org-roam.
It uses a SQLite database to keep track of files and UUIDs, so multiple user access is going to be difficult.
It uses a SQLite database to keep track of files and UUIDs, so multiple user access is going to be difficult.
Ah right. I didn’t say it (my bad) but was considering relying on the property that the “SQLite DB contents can be regenerated from the files” (in this case on a periodic basis or in conjunction with a git operation to push or pull new data).
I use org-wiki and did try out org roam for a quick test.
Isn’t the main problem with org roam or similar solutions that the file names are random?
I quite like having searchable names. I’m a bit worried that when the database is lost I have a problem recovering the metadata.
Isn’t the main problem with org roam or similar solutions that the file names are random?
I quite like having searchable names. I’m a bit worried that when the database is lost I have a problem recovering the metadata.
In org-roam v2, file names are definitely not random.
For example, when calling org-roam-node-find to create a new note, say I type "This is My New Note". The file created is named "this_is_my_new_note.org".
Here's an article regarding workflow from the maintainer that I found quite helpful: https://jethrokuan.github.io/org-roam-guide/
For example, when calling org-roam-node-find to create a new note, say I type "This is My New Note". The file created is named "this_is_my_new_note.org".
Here's an article regarding workflow from the maintainer that I found quite helpful: https://jethrokuan.github.io/org-roam-guide/
I was also worried about filenames, the database, custom ids and all that. It all felt over-engineered for my modest purposes. In true Emacs spirit, the logical conclusion was that I had to implement my own Zettelkasten system:
https://github.com/tmalsburg/mwk.el
https://github.com/tmalsburg/mwk.el
The database in org-roam is a cache for performance. It can be removed at any time and it will be rebuilt from the metadata contained in the files.
org-roam file names are configurable (see org-roam-template slug formation), by default are ctime timestamp followed by note title stripped of eventual special char/spaces. Beside that personally when I need more than just direct heading search&narrow and org-ql is overkill a simple counsel-rg (or consult, helm etc depending on your taste) works very well so I'm feeling exactly no need to access notes via filesystem.
Actually using org-attach and linking I essentially chased to use the classic filesystem + file manager for almost all my in-home activities, everything is accessed via org-roam-node-find and works beautifully well.
Actually using org-attach and linking I essentially chased to use the classic filesystem + file manager for almost all my in-home activities, everything is accessed via org-roam-node-find and works beautifully well.
I don't think org-roam uses random filenames nowadays. When I add a new page to my org-roam instance, I choose the filename and a UUID is added to the page's header.
I have been using emacs and org-mode for years now, but org-roam was a bit tedious and time consuming to set up correctly. I now use Logseq, and it's really great (especially the flashcard feature). I wish it had an emacs mode though.
You can customize the bindings in logseq. I've customized mine[1] to bring them as close as possible to default Emacs and Org mode bindings.
[1]: https://github.com/kaushalmodi/dotfiles/blob/master/logseq/l...
[1]: https://github.com/kaushalmodi/dotfiles/blob/master/logseq/l...
Can somebody explain to me how Org Roam Notes format is any different than Markdown with some [[clever]] indexing on like... tagging + indexing certain parts of your notes to make them searchable?
Why does it have to be different? Org-mode is about a year older than markdown and there’s a whole ecosystem inside of emacs you can leverage (notebook-like code execution with org-babel, literate programming, agenda/calendaring, etc.). You could probably build this all on top of markdown (although Markdown’s syntax is much more limited, something like Mediawiki markup would probably be better) but it already exists if you already use emacs.
That's the gist of it to me.
(Forgetting for the moment the advantages of org over md)
Relevant emacs init code here (a lot of hacks to get exporting to ox-hugo to work and improve performance): https://github.com/alexkehayias/emacs.d/blob/master/init.el#...
I find navigating notes with an interactive graph as not that useful for others. I mostly use org-roam-ui myself to spot notes with no links but otherwise there's way too many nodes to do anything other than randomly click around.