From: Florin Boariu <florin.om@rootshell.ro>
To: emacs-orgmode@gnu.org
Subject: org-ditaa woes
Date: Thu, 19 Oct 2023 12:59:59 +0200 [thread overview]
Message-ID: <ZTEML8zWrB6kQflk@toolbox> (raw)
Hello everyone,
I am not on the mailing list, so I'm hoping that some kind soul with
moderator powers will have mercy and let my email through in a timely
manner :-) Also, please CC me in on the answer. (I'll happily
subscribe if you feel that I should, but this is likely to be my only
encounter with the Org-mode list, so it's probably bogus...)
To my problem.
What did I do
=============
I was trying to create a diagram e.g. from the following org-mode
snippet:
> #+begin_src ditaa :file network.png
>
> +------+
> | moo |
> +------+
>
> #+end_src
My init.el eventually gets to parse this configuration:
> (org-babel-do-load-languages 'org-babel-load-languages '(
> (python . t)
> (ditaa . t))
> )
>
> ;(setq org-ditaa-jar-path "/usr/bin/ditaa")
> ;(setq org-ditaa-jar-path "/usr/share/java/ditaa.jar")
> ;(setq org-babel-ditaa-java-cmd "/usr/bin/ditaa")
> ;(setq org-babel-ditaa-java-cmd "flatpak-spawn --host toolbox run ditaa")
There are several attempts on setting org-ditaa-* variables, or
org-babel-ditaa-*, but all fruitless (see below).
I pressed C-c C-c in order to have a diagram generated.
What did I expect would happen
==============================
The documentation says that a "#+results" section will appear, and it
will contain a link to the ditaa document.
Obviously I'd expect to have a network.png file appearing somewhere on
my filesystem, too, or a PNG inlined into my ORG document. Or
something.
What happend instead
====================
A "#+RESULTS: ..." section with [[file:network.png]] does indeed
appear, but no network.png is to be found anywhere. Clicking on
network.png only opens a new and empty buffer named "network.png",
without any contents.
Essentially, the error messages I find in '*Messages*' so far vary,
depending on which org-ditaa / org-babel-ditaa variables I set, and
how I set them. They range from:
> org-babel-execute:ditaa: Could not find ditaa.jar at /app/share/emacs/29.1/lisp/contrib/scripts/ditaa.jar
via:
> Error: Invalid or corrupt jarfile /usr/bin/ditaa Code block evaluation complete.
to:
> Error: Unable to initialize main class org.stathissideris.ascii2image.core.CommandLineConverter
> Caused by: java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException
> Code block evaluation complete.
I'm fairly sure I know *why* this is the case, just not how to fix it.
...actually, I'm fairly sure that it can't be fixed on my part :-(
Essentially, emacs / org-babel tries to either execute "java -jar
/usr/bin/ditaa", or doesn't find any jar file, or finds one in
/usr/share/... but fails to actually make it run.
A little bit more background.
I have what would be considered an "exotic setup", although it's
pretty standard for the Linux distribution I'm using (Fedora
Silverblue):
- My Emacs (29.1 apparently?) runs in a Flatpak
- All other applications, including ditaa, run in a "Toolbox"
(https://containertoolbx.org/). Think: kind of a "mutable Docker
container". Think of it as of a chroot'ed environment where
everything else that isn't X-windows or Gnome is installed, and
that only shares /home/me, /var, and a few other non-relevant
directories with the host system. In particular, it does *not*
share /usr, /bin, /lib or anything of importance for applications.
- ...alternatively, I can run an Emacs instance (a 28 version) in
the same toolbox as the other applications (i.e. ditaa), but the
results are the same.
- ditaa within the toolbox is my "distribution standard", which is
an executable file at /usr/bin/ditaa, and which apparently is a
shell script with the following contents:
#!/usr/bin/bash
#
source /usr/share/java-utils/java-functions
MAIN_CLASS=org.stathissideris.ascii2image.core.CommandLineConverter
BASE_JARS="ditaa commons-cli xml-commons-apis batik"
set_classpath $BASE_JARS
run "$@"
This is to show that it's similar to, but still quite a bit more
than just "java -jar ditaa.jar ...". This appears to be standard
e.g. for all Fedora distributions (and alike). FWIF, latest Debian
does something similar, only that /usr/bin/ditaa there is a
binary.
The core of the problem
========================
Essentially, org-ditaa expects a jar and a java runtime to be able to
consruct a command line of the kind "java -jar /path/to/didaa.jar ..."
and expect everything to sail smoothly. And it's *very* opinionated
about that.
There's no way that I can provide that without a significant amount of
ugly hacking. What I can offer are a myriad of workarounds, but all
boil down to specifying a shell command that does what org-ditaa
expects, but doesn't begin with "java -jar ...". This is simply
because the premise -- namely that emacs, org-ditaa, ditaa.jar and
java-runtime, are in the same filesystem namespace, or the same
process namespace, is simply not true for me. This is by design --
both of the distribution I'm using, and of the whole Flatpak
ecosystem.
Where to go from here?
======================
So... yeah.
This is where I stand. What options do I have?
Besides the obvious "use another distribution" I essentially have two
options, and they both begin with "download a fresh ditaa.jar from
Sourcerforge, independent of the one distributed with your Linux, and
then...":
1. either patch the Flatpak to actually include this, and refer to
it from org-ditaa-jar-path, or
2. copy it somewhere into your "toolbox" filesystem namespace and
refer to it from org-ditaa-jar-path,
"...and then do this again every time you update your Flatpak or your
Toolbox (which is every couple of days)."
Now that I think of it, there is actually another one:
3. Manualy download and put a ditaa.jar somewhere in
"~/.emacs.d/..." (the home folder is persistent even in most
sandboxes).
But Flatpak-emacs doesn't include a java runtime, so I'd still be
stuck at "java -run ...". However, this would at least enable me to
work with my toolbox-emacs -- albeit at the cost of having to manually
download a .jar file, of which a perfectly fine copy is delivered by
my distribution's package management already.
I wasn't able to find in-depth documentation on how to manipulate
command lines for org-ditaa (if there is any available, please kindly
point me in the right direction -- I looked
mainly at
https://orgmode.org/worg//org-contrib/babel/languages/ob-doc-ditaa.html
and
https://github.com/bzg/worg/blob/master/org-contrib/babel/languages/ob-doc-ditaa.org
and various stackoverflow and github bug reports.)
But in the source code of org-ditaa.el
(https://github.com/tkf/org-mode/blob/master/lisp/ob-ditaa.el) I can
see something like this on lines 87 ff:
> [...]
> (cmd (concat "java " java " " org-ditaa-jar-option " "
> (shell-quote-argument
> (expand-file-name
> (if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
> " " cmdline
> " " (org-babel-process-file-name in-file)
> " " (org-babel-process-file-name out-file)))
> [...]
I suck at LISP, but I'm guessing this means that there simply
is no way of just passing on a "/usr/bin/ditaa" command-line to
"org-ditaa", or at least an alternative Java command like "flatpak
spawn --host /usr/bin/java ...". Org-ditaa really *does* insist of
glueing it together from "java -jar ..." pieces, and is stubbornly
adamant on finding Java in the same FS namespace.
Is there a deeper reason behind this? This pretty much breaks
Flatpak, or any other sandboxing compatibility, as far as I
understand. Can it be changed? Please? :-)
How can I make it accept a command line?
Is there any "generic" way of making org-babel accept a command line,
not necessarily going through "org-ditaa", as a workaround?
Thanks & 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 /.
next reply other threads:[~2023-10-20 10:31 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 10:59 Florin Boariu [this message]
2023-10-20 17:22 ` org-ditaa woes Leo Butler
2023-10-20 18:16 ` Dr. Arne Babenhauserheide
2023-10-20 19:31 ` Leo Butler
2023-10-20 21:39 ` Florin Boariu
2023-10-21 3:50 ` Max Nikulin
2023-10-23 11:18 ` Florin Boariu
2023-10-24 7:55 ` Max Nikulin
2023-10-24 9:31 ` Florin Boariu
2023-10-24 9:38 ` Ihor Radchenko
2023-10-25 19:00 ` Leo Butler
2023-10-26 8:44 ` Max Nikulin
2023-10-26 9:30 ` Ihor Radchenko
2023-12-20 18:03 ` Leo Butler
2023-12-21 14:15 ` Ihor Radchenko
2023-10-26 15:32 ` Leo Butler
2023-10-23 12:25 ` Florin Boariu
2023-10-21 7:44 ` Dr. Arne Babenhauserheide
2023-10-21 8:56 ` [TASK] Allow customizeable ditaa executable in ob-ditaa.el (was: org-ditaa woes) Ihor Radchenko
2023-11-09 3:17 ` [TASK] Allow customizeable ditaa executable in ob-ditaa.el Leo Butler
2023-11-09 12:17 ` Max Nikulin
2023-11-10 3:19 ` Leo Butler
2023-11-10 10:09 ` Ihor Radchenko
2023-11-10 10:38 ` Max Nikulin
2023-11-10 15:21 ` Leo Butler
2023-11-11 10:07 ` Ihor Radchenko
2023-11-10 10:18 ` Ihor Radchenko
2023-11-10 14:59 ` Leo Butler
2023-11-11 10:24 ` Ihor Radchenko
2023-11-13 16:26 ` Leo Butler
2023-11-15 11:12 ` Formatting worg code examples (was: Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el) Max Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTEML8zWrB6kQflk@toolbox \
--to=florin.om@rootshell.ro \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).