Org-roam major redesign

Development
62

I meant just Org IDs.

63

Oh, yeah, it feels like a whole new world, @jethro.
Just tried with test files for now to get used to it.

I like it :slight_smile:

  • It looks better
    org-roam-buffer looks more inviting and functional. With widgets, I believe it will be easier to invite tinkerers to contribute their own ones. You and project can focus on the core; the community can tinker and share extensions.
  • It feels a lot more streamlined
    Not just about going all in with Org-id. By the looks of it, org-roam-setup can be put into the after-save hook, which I think I would do, or be added to another more sophisticated chain of functions. I guess this will save a lot of questions around 2-second waiting, or immediate DB update, and so on
    [EDIT: nope. Apparently, that’s not what I will do :wink: org-roam-setup is for initial setup to add hooks and advice that Org-roam requires; org-roam-teardown seems be used to deactivate all this]
  • Personalizing org-roam-buffer placement looks easier
    It looks to be just another window (no longer a buffer in a side window) by default… I imagine that personalizing where and how it gets displayed can be easier with display-buffer-alist and other built-in facilities.

Very open and frank feedback. As I find V2 encouragingly good, I think it deserves some plans or even just anticipation of how users might respond to it when it finally launches.

I could anticipate a lot of “migration” queries from V1 users, and even with new users starting directly with V2, as all the YouTube, blogs, and other instructions that community has put together so far will need to be revised. There will be void of community-based knowledge base for new users to fall back on, at least in the initial phase.

All this means there will likely be a lot of backlog questions to answer, leaving little breathing space for you and the project to keep going with V2.

Maybe I am thinking too much, and you can just swim through the new water with no problem, knocking off questions as they come. But I will be happy to do some early documentation of some sort, if it helps, of course (I cannot do this until at least end of March in the current plan of my other pressing engagements).

As an idea… We could start a wiki that collects V1 → V2 migration issues and solutions. It could be in this forum, or the wiki page in GitHub repo. It does not have to be a long-term thing, so just something that can be quickly put together would be good enough. Just a thought.

My personal example of an issue just to illustrate my point. This is not a problem for me, and certainly not something I am requesting for change. But these things will likely pop up, and I think it would be better if we had some documentation to point people to.

org-roam-open-id-at-point seems to have been removed. This means my manually typed/generated ID won’t work as a link [[id:123]] as it won’t be recognized by org-id-find even when Org-roam has no issue in finding it as a backlink. My custom timestamp ID won’t work. Not an issue; I just need to think this through.

1 Like
64

Hmm, what issues do you see with your manually typed ID’s? I seem to have no issues on my side. Guessing a bit: Maybe you need to trigger org-id-update-id-locations after you’ve created the ID’s for Org mode to recognize them?

66

Oh I see. That may be the solution. I’ll try (away from PC now). Good to know. Thank you.

I think my point about need for documentation still stands. There needs to be additional knowledge to be learned. I take it as a positive challenge, but some people would need a bit easier transition.

Edit: Great. It works. I need to specifically call the command with the file as an element of the FILES list argument… Really good to know. I was going to do some research to see if there was a way. Thank you. Need to find a good spot to call this :wink:

67

This is something I am considering adding back though, I just deleted a lot of non-core stuff, to add back later if necessary.

1 Like
68

I think it would be much easier to forget that v1 exists, and learn v2 on its own. Those currently using file links will have all their org-roam files create org-ids for each file on first cache build. Migration is just a matter of looping through all files and replacing file links with id links where possible.

Now that Org-roam is much simpler, documentation should also be easier. This is something I will get right before releasing v2.

3 Likes
69

Sure. Technical moving and changing the file links will be easy enough. I’m looking forward to using V2 more, and for your documentation.

My “migration” point is that Org-roam never exists in a pure Emacs environment - always used in conjunction with other distro and packages. Many of the troubleshooting and queries I have had a chance to interact with are related to actual usage in the wild where Org-roam used in combination with something else.

Maybe it’s just me over thinking. The “in the wild” issue is not unique to V2. It’s just that I can anticipate many questions in the from of “I was doing X with V1; how do I it with V2?”. Perhaps it’s a matter of unlearning V1 and learning V2 anew.

70

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.

I am curious, by preview do you mean just the text around the link reference or something else?

71

That is kind of sad news because especially org-roam-server is a nice way to navigate through the graph. Filed an issue about the v2 plans on the org-roam-server GitHub site, but no reaction so far. :frowning:

Nevertheless, thanks for all the work you’re putting into the project.

2 Likes
72

Rainer Koenig via Org-roam orgroam@discoursemail.com writes:

That is kind of sad news because especially org-roam-server is a nice way to navigate through the graph. Filed an issue about the v2 plans on the org-roam-server GitHub site, but no reaction so far. :frowning:

It will break, but I have no doubt it will be fixed. You can still stay
on the v1 while the org-roam ecosystem stabilizes :-).

1 Like
73

This is looking beautiful, thanks for the hard work!

74

Does org-roam-insert work with the v2 branch? I’m not sure how to build links with the new branch.

75

org-roam-node-insert

76

Thanks, I was using org-roam-insert.

77

For v2, What do you think about adding “file creation time” to file meta data. It is useful to view files that have been created within a range of days.
I currently use ‘#+created:’ keyword to manage this (I believe the default templates populate it), I would like this to reside in the database as well so that the script I use doesn’t need to parse my whole org-roam directory and only needs to query the database.
It would be parsed like org-tags keyword and placed in the database.

2 Likes
78

I’ve thought about it before, but file creation time is not part of the Unix API, and any other way of tracking created time would be non-standard. Org-roam stores atime and mtime but actually doesn’t do anything meaningful with it now (used to be for sorting, but not anymore, at least not yet)

One way is to use some form of VCS, and use the VCS stats instead. I think this sort of versioning plain text files makes a lot of sense, but I haven’t really thought deeply about how to enhance their interactions.

79

Will the v2 changes make it possible to filter backlinks? E.g., in my workflow it would be very useful to hide all the backlinks that originate from daily notes and only see those backlinks that originate from ordinary notes.

1 Like
80

Not in the initial release, but is trivial to add.

81

Does it mean a version control system?

How about leaving an abstraction here and let the end-users build their own? For example, making a variable

  • default not saving file/headline creating time
  • UNIX system
  • other systems
82

Although it is not part of the UNIX api, ext4 file system supports it. stat command returns creation date among other things.
I don’t know about windows or mac.

I think the easiest way is to use the keyword created much like roam_tag and roam_alias because, this way, org roam can support this feature with minimal change to file parsing, capture template and database update. It would also lend it self to custom workflows because it makes it easy to implement personal timestamp across files that is supported by org roam (for example if one wants to track something else than creation time).

In the future, filesystem and os centric methods can be implemented to augment this feature.

I started tracking created time along with last_updated within the file through recommended templates I found online (either in the docs, this discourse group or github issues). I don’t know if it is well spread (maybe we can do a poll). The default capture template is bare because it doesn’t use supported keywords. It can be updated to include this keyword among others for future files.

why was this discontinued? It sounds useful and it is possible to place sort over title length with it (either sort by date then by title length or the opposite).