Re: org-ditaa woes

[Florin Boariu <florin.om@rootshell.ro>]

On Sat, Oct 21, 2023 at 10:50:08AM +0700, Max Nikulin wrote:

>Does it work when executed from Emacs shell or eshell buffers?
>
>Could you, please, provide complete sequence of commands to generate a 
>graphics file from a ditaa source for a shell running in Emacs?

"M-x shell" and then:

> sh-5.1$ echo -e "+-----+\n| moo |\n+-----+\n" > /tmp/foo.txt
> sh-5.1$ cat /tmp/foo.txt 
> +-----+
> | moo |
> +-----+
> 
> sh-5.1$ flatpak-spawn --host toolbox run /usr/bin/ditaa /tmp/foo.txt -o /tmp/foo.png
> 
> ditaa version 0.9, Copyright (C) 2004--2009  Efstathios (Stathis) Sideris
> 
> Running with options:
> overwrite
> Reading file: /tmp/foo.txt
> Rendering to file: /tmp/foo.png
> Done in 0sec
> sh-5.1$ 

...gives pretty much the expected result, which is a PNG image of the
word "moo" embedded in a square. Is this what you hoped for?

>Flatpack is a means to prevent accessing system files by applications 
>that may have less degree of trust. I expect that a package should be 
>carefully prepared to allow `man' and `info' access docs installed 
>system-wide, files from /usr/share/doc should be available for 
>doc-view, compiler toolchains should be available if Emacs is used for 
>development. It sounds like rather broad permissions for isolated 
>applications.

...I'm not an expert of Flatpak, but it is my understanding that it
uses something they call "portals" for defined access to your file
system. Apparently it's a bit more sphisticated than "just" broad
access.

For instance, once you have an application that requires to process a
file, you're presented with a dialog window by the OS (*not* by the
application) with which you can select your file. The file is then
opened for you, and your application only has the option to write to
that specific file -- and nowhere else. (Please don't fact-check me on
this, I really am just parroting concepts here... :-p)

This doesn't sound a lot like Emacs, and in fact I'm not sure how the
Emacs Flatpak works. Given that it's an "editor" designed to "edit"
everything, maybe it is indeed opening up most/all of the whole
host filesystem (?), has very little in the way of actual isolation
(??), and just uses Flatpak as a "package manager on steroids"
only to keep its own dependencies private (???).

But even this broad access to the host system isn't of any help to
me. This is because of the way the Fedora Silverblue distribution
works: the "bare linux" you boot into doesn't contain anything
beyond bare Wayland/Gnome desktop shell and essential system tools
(systemd, networking, DNS resolving, user management...). This is a
read-only ("immutable") image, like a perpetual, bare-bones "live
ISO" (courtesy of "libostree", https://ostreedev.github.io/ostree/ if
you're interested).

Any other applications -- gcc, python, additional libraries,
development tools, ditaa etc -- are being installed in a kind of
mutable container technology ("toolboxes", see
https://containertoolbx.org/ ). Those are pretty strongly isolated
from the host file system, and essentially only share the $HOME folder
and some state (/var, /proc, /dev, ...) with the host.

(This is a simplified view of things, but that's the gist of it.)

This means that even if the Emacs Flatpak was to give broad access to
the host, I still wouldn't be able to call "java -jar ...", simply
because the host system isn't meant to, and generally doesn't, even
have Java runtime to begin with, a ditaa.jar, or a /usr/bin/ditaa.
Those are meant to exist in toolboxes.

The command line above ("flatpak-spawn --host toolbox run [...]") is
designed to cross two namespacing boundaries:

   - "flatpak-spawn --host [...]" breaks out from the Flatpak,

   - "toolbox run [...]" then executes a command inside a toolbox
     (e.g. "/usr/bin/ditaa").

The way they share data is worth some thought, but we incidentally get
lucky here: Emacs writes the code into "/tmp/...", which is shared
and accessible across all namespaces; and /usr/bin/ditaa read that,
and writes the PNG in the current project folder (in $HOME), which, in
this case, is also shared by emacs.

Hope this helps a bit to see the context of my request :-)

I really _need_ to generically execute a command.

>Menu: Org → Documentation → Show version, Help → About Emacs
>or M-x org-version

"9.6.6 (release_9.6.6 @ /app/share/emacs/29.1/lisp/org)"

> M-x emacs-version.

"GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.16.0), of 2023-08-06"

Cheers,
Florin.

-- 
    "Socks come in pairs. If you put a sock on your left foot, the other
     sock of the pair instantly becomes the “right sock,” no matter where
     it is located in the universe."
                                  -- quantum entanglement explained on /.