This year I put a lot more work into #Orgro (https://orgro.org). I released a bunch of big features:
- Search result navigation UI
- SVG support
- Editing support! 🎉
- Undo/redo
- Jump to/from footnotes
- Support for local variables, #+STARTUP settings
- (Soon!) Decryption/reencryption of Org Crypt sections
The wildest yak shave I went on was support for local variables: I made an entire Elisp execution engine in order to support the `eval` keyword! (Don't tell Apple 🤫)
@mtekman I am not planning on it, sorry. In fact unless the SQLite DB had an official stability guarantee I wouldn't consider it at all. According to the manual it appears it does not:
@ParetoOptimalDev @amake I recall there being some ambiguity on using ones own SQLite dB, or using Emacs internal one. Since v28, I've been using Emacs sqlite dB for org-roam and its pretty stable for me
I can't imagine the org-roam dB schema changing too much either. The root path and the links must exist in each record.
That being said I have no idea what the overhead is in syncing an Emacs sqlite dB with an Android one, but I can imagine there's a level of complexity I haven't considered
> using ones own SQLite dB, or using Emacs internal one
As I understand it, your options are in which library to use to manipulate the DB within Emacs. This has basically nothing to do with the schema of the DB contents, which is singular and specific to org-roam and is subject to change at the whims of the org-roam devs as org-roam itself evolves.
I’ve never seen an app commit to a stable DB schema because that would severely hamper future development. Usually you would have a stable API *on top* of the DB, but in this case that would mean the org-roam devs publishing a package for Dart; I have a hard time imagining they would want to do that.
@amake @ParetoOptimalDev That's fair. I'd say org-roam development appears to be pretty steady (read: I have an open PR there since July[0]), and there would be no demand from me to implement the full org-roam spec. Just a quick way to switch between org-roam files would be enough, without making any changes to the DB.
If I open the tiny db at `brain/org-roam.db`, I can see that the first 2 columns of the `node` table are enough to traverse all org-roam links.
Add function for filtering links before cache insertion: For a given link type, include/exclude all links of that type unless the paths optionally match case-sensitive strings. Motivation for this...
Aaron “Abolish ICE” Madlon-Kay
Mehmet Tekman
ParetoOptimalDev