I hope, a couple of workarounds are still possible.

1. Get java command by adding bash -x (or /usr/bin/bash, or "/usr/bin/env bash")

   flatpak-spawn --host toolbox run bash -x /usr/bin/ditaa \
       /tmp/foo.txt -o /tmp/foo.png

- set `org-babel-ditaa-java-cmd' to something like
   "flatpak-spawn --host toolbox run /usr/bin/java",
- set `org-ditaa-jar-path' to path to ditaa.jar reported by the command above,

There are a lot of assumptions baked into this one, for starters: that
I can actually do "java -jar $PATH_REPORTED_BY_COMMAND.jar" actually

It doesn't:

    sh-5.1$ flatpak-spawn --host toolbox run java -jar /usr/share/java/ditaa.jar
    Error: Unable to initialize main class 
    Caused by: java.lang.NoClassDefFoundError: 


- add other options to either `org-babel-header-args:ditaa' :java property or to `org-babel-ditaa-java-cmd' - perhaps add /usr/bin/env JAVA_HOME=... and other required environment variables before java binary.

...and now I, despite not being a Java developer, need to figure out
how to debug the execution of a program I didn't develop (in a
language I'm not familiar with), and for which a perfectly functional
script was _already_ delivered by my distribution in the form of
"/usr/bin/ditaa" ;-)

What actually _does_ work (and what I'm currently indeed using as a
workaround) is download my own copy of ditaa.jar from their website,
put it under ~/.local/share/ditaa/ditaa.jar, and set
'org-ditaa-jar-path' to that specific value.

This still leaves me with the necessity to download a package through
a side channel which already exists in my distribution as a pacakge,
but at least I don't need to get into the bowels of Java to run it.

- set `org-babel-ditaa-java-cmd' to
 "flatpak-spawn --host toolbox run /usr/bin/ditaa".
- set `org-ditaa-jar-option' to empty string.
- Call of `shell-quote-argument' makes it impossible to set `org-ditaa-jar-path' to empty string, so set the following variables to some harmless value, e.g. "-Dfile.encoding=UTF-8" (anything added through :java babel header argument):
 + `org-ditaa-jar-path'
 + `org-ditaa-eps-jar-path'

I'm not sure whether I had thought of that (-Dfile.encoding is not
recognized by recent ditaa, BTW, I think they have a new option for
that). I think I had, but got stuck at "set org-ditaa-jar-option to
empty string" :-D  IIRD it threw an error (the one you said it would),
and that's where I stopped investigating.

I agree that it should be possible to call ditaa executable directly. Perhaps it is not possible because for a long time ditaa.jar was a part of Org mode repository (there were a lot of messages against dropping of jar files from the repository).

I'm not sure having the .jar in the repository would even help in my
case, unless the Emacs Flatpak specifically also shipped with a Java
runtime. (And I think we agree that this shouldn't happen -- Emacs is
a perfectly usable OS in its own right, no need for Java on top ;-) ).
Because otherwise the .jar would be inside the Flatpak, and the
runtime would be somewhere else from where it couldn't access the .jar.

It seems, nobody is ready to take responsibility and to become
maintainer of ob-ditaa.el while active users have no ability to
install ditaa as a package, so they anyway have to download .jar from

I can offer to try my luck with writing a patch for ob-ditaa.el, but
I'm not knowledgeable enough (or have enough time on my hands) to
actually keep maintaining it :-p

I find it tedious to add "flatpak-spawn ..." to every tool used by Emacs. Who is the publisher of the flatpak? I would expect a directory with symlinks named ditaa, java, git, gcc, cpp, etc to a script line

exec flatpak-spawn --host toolbox run /usr/bin/env "$0" "$@"

(or "$(basename "$0")")

mounted to flatpak runtime and added to $PATH. Perhaps another approach exist and it should be discussed with the packager and Emacs developers.

It's a double-edged sword. Not every Flatpak distribution actually has
a Toolbox infrastructure, too... (Flatpak didn't get invented with, or
for, Fedora Silverblue; it was around for a long time before that. But
Toolbox did.) So for most, "flatpak-spawn --host $CMD" would be the
way to go, not "...toolbox run $CMD". And even in Toolbox systems,
there can be more than one toolbox, so some might want to run
"...toolbox run -c gcc-devel $CMD ...", where "gcc-devel" is a
specific toolbox for GCC development.

But with regards to the Emacs Flatpak: gcc, cpp and gitare part of it:

    sh-5.1$ which git
    sh-5.1$ which gcc

(I'm guessing they're actually part of the underlying SDK -- Flatpaks
apparently are a kind of "layered system", where specific applications
can build upon the same support).

But Java and Ditaa aren't:

    sh-5.1$ which java
    which: no java in 

So... 🤷

But that's the joy of experimental operating systems. When people
start toying around in non-standard ways, there's always something
that doesn't add up, or requires manual intervention even for trivial
tasks. If anybody, then Linux people in general, and Emacs people
specifically, should have made this their credo by now :-D

It used to be like this 25 years ago when I started with Linux, when
you couldn't even start a benign GUI without enchanting the XFree86
drivers for days. And it's the same today, just differently.

Today we have Live ISOs, Steam for Linux, and a famous Redmond company
timidly nudgnig their users towards a smoother Linux desktop than
Windows ever was. But thankfully, containers and sandboxing and all
the rage are here to "help", and thus old and comfortable patterns
start becoming modern again... :) Flatpak's the new Black, baby! :-D

(Now if you'll excuse me, I need to scream at some kids to get off my
lawn... :-p )


   "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 /.

Reply via email to