Hi gang, I’ve taken on a member role in the org-roam organization to help shepard the project along. This year I was able to bring things up to speed with built-in SQLite support for Emacs 29 and later, and work through CI issues. We have started addressing what I think is the biggest class of issues: performance. A PR to improve org-roam-node-find performance was recently merged, and v2.3 was released to melpa-stable (after 3 years since the last release).
I won’t be doing the lion’s share of active development myself, but will support those who do — and there are a few eager folks working at it.
There are a ton of open issues and PRs in GitHub and a lot of them are quite old and have gone stale. I’m going to set up a workflow to auto-close dormant issues after 6 months of inactivity with a 2 week warning comment. If you have an issue or PR that you’ve been following and would like to see attended to, please give it a ping in the comment thread.
I love org-roam. I use it every day. I appreciate this community and look forward to giving back.
To see some perf fixes for the *org-roam* buffer, you can check out what org-node-roam-accelerator-mode does! I meant to upstream at some point but, uh, life. Happy to answer any questions.
@dustinfarris Thank you for all you do! Happy to see v2.3 published. You are doing herculean work.
Perhaps I can join force with you, do my bits and try to update the documentation – I have been wanting to go back to Zero-to-Emacs-and-Org-roam guide – but instead (and additionally), I could send some PR for the official documentation to be in line with Emacs 29 with SQLite embedded… Not immediately. I am pacing myself, looking at the rest of year 2025.
Thanks @nobiot — your past contributions and participation in the community are a big part of what makes org-roam great. No pressure to do all the things all at once. I would like to see the following done by EOY, somewhat in order of priority:
You might be surprised to find it gets even faster if you also let-bind org-agenda-files to nil before enabling org-mode.
And org-element-cache-persistent - as it’s a temp buffer, it just causes unnecessary work as far as I’ve understood. Perhaps that should be considered an upstream bug.
Thanks a lot for picking up maintenance. I happened to revisit an old issue and noticed the stale bot. I went ahead and commented on a few issues that got closed that I think are still relevant (I’m hpfr on GitHub).
Given the dormant period, I think attempting a reset on the open issues is reasonable. But can we maybe not lock them? Unless there is a big pattern of users commenting on old unrelated issues (doesn’t seem like it), it helps avoid needlessly fragmenting issues when the stale bot closes one prematurely and forces people to open a new duplicate.
Feel free to add me to the repo to help triage issues if you want. I also have an old PR I should revisit…
Hey @Liam! Thanks for sifting through the closed issues, and thanks for voicing your thoughts on the issue lock automation. You’re right, it is heavy-handed. I went ahead and disabled it.
I’ve added you to the repo with write access. Feel free to reach out to me if you want to discuss anything one-on-one — my email is on my GitHub profile. I would like to say here in this forum that I don’t plan on unilaterally adding any future collaborators to the repo. For my part, if someone else wants to be added, I’ll seek consensus from the active collaborators.
Thanks Dustin. I took a look at the most upvoted issues closed as stale to provide better resolutions where possible. I also opened a PR to clean up the docs build so we don’t need ox-texinfo+ anymore:
I went through a ton of stale issues and reopened a bunch I believe are relevant. There’s still a ton of cruft the bot cleared out, thankfully. I set up a milestone for 2.4.0 based on fix PRs that have been open for a long time plus some other cleanup. I am pretty much on board with Dustin’s priorities in #7 (you got lucky with your unilateral addition ).
I am somewhat concerned about the capture-related issues; upstream Org capture is really convoluted and Org-roam’s additions don’t exactly help the situation. My thinking is to do those last and maybe set up a branch with the fixes for power users to test. If anyone has (or wants) experience there, your assistance is most welcome.
Once the bugs are under control I agree performance needs some attention. In the issues it looks like @akashp and @dmg (and @meedstrom1 before he seceded ) have some good threads to pull on.