I have long used Ulysses on Apple, a writer’s editor that uses Markdown. On migrating away from Apple I discovered it exports to Textbundle, which can incorporate images by embedding their urls within the text. According to its website:
The TextBundle file format aims to provide a more seamless user experience when exchanging plain text files, like Markdown or Fountain, between sandboxed applications.
We know that Genode is a strong user of sandboxing so this format seems ideal for a native format for text that needs to link to images and other stuff. Almost all the applications (they are listed at page linked above) using this format are for Apple family of OS but if Swift language was on Genode then perhaps some of those could be ported. Non Apple implementations include Keepmark and Zettlr.
I would certainly use a native Sculpt app with this format to retain access to my work from Ulysses. But perhaps there is the opportunity to make deeper use of it in Sculpt, such as for system documentation etc?
Zettlr appears to be Electron-based, and Keepmark development has been suspended; I also haven’t been able to locate a copy of its source code.
I hope to eventually port Emacs to Genode, and while there is a working emacs package for textbundle, it seems to be vibecoded. Furthermore, image display is only possible in the Emacs GUI, which relies on GTK, and is therefore not yet supported on Genode.
It looks as though the format is designed to circumvent sandboxing restrictions rather than provide a sandboxed approach. Since the format is simply a ZIP file containing metadata, assets, Markdown, etc., a non-WYSIWYG workflow using Vim on Genode would be feasible, provided zip/unzip utilities are available.
I suspect any system documentation component would be static and self-contained, eliminating the need to use Textbundle. Additionally, since the links to the assets are tied to the bundle structure, you cannot separate the text file from the bundle without breaking those links. This would likely require maintaining both a file with a plain link and a textbundle-specific link, since Textbundle can’t be read as plaintext without extraction.
The idea of using a documentation format other than GOSH has been discussed before, but has not yet been realised. Markdown is the popular choice, but given my interest in porting Emacs, I feel it would be remiss not to mention Org-mode.
The differences in markdown implementations is nontrivial, to which the markdown monster (github render) perfectly illustrates.
I had to read up about GOSH, never knew about it before. It is true that Markdown is a bit of a dog’s breakfast and in many ways the worst option was that which became the most popular (like Windows did in the 1990s).
With that in mind I agree that keeping “our own” type of markdown would be a benefit, like using HRD rather than XML for the config files. A hypothetical native editor could offer this along with another markdown syntax. Perhaps including a “textbundle” file format as well.
I am not quite sure what you mean by this. My understanding is that running in the sandbox is deemed necessary safeguard if the document is empowered to be pulling in resources from all over the web.
Perhaps a benefit of linking images is that when the software is updated and perhaps the order of a menu changes, we can have the external image updated to reflect this without changing the local text?
Well, to overcome the “inconveniences” and permission fatigue of having to explicitly grant the application access each image, the solution was to dump all the assets into 1 file. You therefore trade security for convenience, since you now grant permissions to a single opaque bundle rather than individual files. For example, application A can do whatever they want to the file in a way that is invisible to the user, such as adding a malicious png, that then gets sent to application B.