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 🤫)
The previous contribution graph is for Orgro, but a lot of the work was in underlying MIT-licensed libraries (as opposed to Orgro, which is GPL-3):
- org_parser: pure-Dart parser for Org markup
https://github.com/amake/org_parser
- org_flutter: widgets for rendering Org markup
https://github.com/amake/org_flutter
- petit_lisp: a pure-Dart Scheme implementation (Elisp compat layer provided in org_flutter)
https://github.com/amake/petit_lisp
So to other #Flutter developers: Please feel free to make use of these in your apps!
I submitted #Orgro 1.36.1 for review this morning (1/1 Japan time) and it got reviewed and approved within a few hours 😳
Thanks and Happy New Year to the hard-working reviewers 🫡
@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...
@tim_lavoie There is an issue tracking org-roam support:
https://github.com/amake/orgro/issues/17
It's difficult to support it well on mobile because the way you can access the filesystem is very limited, making resolving ID links to other files non-trivial.
As for (full) editing, making that comfortable on mobile is an exercise in UI design and implementation that may be beyond me.
Kirill Gerasimenko
Aaron “Abolish ICE” Madlon-Kay
Mehmet Tekman
ParetoOptimalDev
Tim Lavoie