org-ditaa woes

org-ditaa woes

[Florin Boariu]

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

Re: org-ditaa woes

[Leo Butler]

Hello Florin,

On Thu, Oct 19 2023, Florin Boariu <florin.om@rootshell.ro> wrote:

> 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...)

You can read (and post to?) this email list on gmane.

> 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 think you have identified a bug in ob-ditaa.el. Your request is
perfectly reasonable and that CMD should not have such hard-coded
constants in it, imo.

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

Can you give us the command-line you would like to use?
That would help to fix the problem you are confronting.

>
> 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? :-)

The deeper reason is likely that ob-ditaa worked for whomever wrote it,
and users have either accepted its limitations (if noted), worked around
them, or gave up.

>
> 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?

You could use ob-shell, but it would be preferable to fix the bug you
have identified.

>
> Thanks & cheers,
> Florin.

Leo

Re: org-ditaa woes

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]


Leo Butler <Leo.Butler@umanitoba.ca> writes:

>>> [...]
>>>        (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)))
>>> [...]

From the commit, this is an ancient version of ob-ditaa (11 years ago).

In my current source I see

	 (cmd (concat org-babel-ditaa-java-cmd
		      " " 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)
		      " " (if pdf-cmd
			      eps-file
			    (org-babel-process-file-name out-file)))))

(use C-h v org-babel-ditaa-java-cmd to see the value of the java
executable — you can then customize this to use a different command)

Going forward we may want to adjust ob-ditaa to allow for an executable
like ob-plantuml does it.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: org-ditaa woes

[Leo Butler]

On Fri, Oct 20 2023, "Dr. Arne Babenhauserheide" <arne_bab@web.de> wrote:

> Leo Butler <Leo.Butler@umanitoba.ca> writes:
>
>>>> [...]
>>>>        (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)))
>>>> [...]
>
> From the commit, this is an ancient version of ob-ditaa (11 years ago).
>
> In my current source I see
>
> 	 (cmd (concat org-babel-ditaa-java-cmd
> 		      " " 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)
> 		      " " (if pdf-cmd
> 			      eps-file
> 			    (org-babel-process-file-name out-file)))))
>
> (use C-h v org-babel-ditaa-java-cmd to see the value of the java
> executable — you can then customize this to use a different command)
>
> Going forward we may want to adjust ob-ditaa to allow for an executable
> like ob-plantuml does it.
>
> Best wishes,
> Arne

Arne,
Thank you for the correction, you are right about the vintage (and
about the suggestion vis-a-vis ob-plantuml, imo).

Leo

Re: org-ditaa woes

[Florin Boariu]

>
>Can you give us the command-line you would like to use?
>That would help to fix the problem you are confronting.

A "regular" one would be just simply "/usr/bin/ditaa":

---
   $ ditaa --help
   usage: java -jar ditaa.jar <INPFILE> [OUTFILE] [-A] [-b <BACKGROUND>] [-d]  
          [-E] [-e <ENCODING>] [-h] [--help] [-o] [-r] [-S] [-s <SCALE>] [-T]
          [-t <TABS>] [-v] [-W]
    -A,--no-antialias              Turns anti-aliasing off.
   ...
---

For instance "ditaa diagram.txt -o diagam.png" would do exactly what
one would expect: translate diagram.txt into the coresponding image.

A more fancy one when using Flatpaks and container toolboxes are
involved would be "flatpak-spawn". E.g. this is what it takes from
within the org.gnu.emacs Flatpak sandbox to run "ditaa" in a Toolbox
container (different sandbox):

---
   $ flatpak-spawn --host toolbox run /usr/bin/ditaa --help
   usage: java -jar ditaa.jar <INPFILE> [OUTFILE] [-A] [-b <BACKGROUND>] [-d]
          [-E] [-e <ENCODING>] [-h] [--help] [-o] [-r] [-S] [-s <SCALE>] [-T]
          [-t <TABS>] [-v] [-W]
    -A,--no-antialias              Turns anti-aliasing off.
   ...
---

(Note that the self-reported message says "usage: java -jar
ditaa.jar...", but this really just behaves like a regular command
line application.)

Replying to Arne's comment:

> In my current source I see [...]
>
> (use C-h v org-babel-ditaa-java-cmd to see the value of the java
> executable — you can then customize this to use a different command)

As far as I understand that part of code it still kind-of assumes that
I'm using a command line of type "java -jar ditaa.jar ...", just with
more flexibility in choosing which "java" command I'm using, right?

I've just tried setting org-babel-ditaa-java-cmd to "/usr/bin/ditaa",
and org-ditaa-jar-option to "", but now the error is something like:

> /usr/bin/ditaa   /orgfile/base/folder  \
>      /tmp/babel-0YxwcE/ditaa-NyIQwH \
>      /orgfile/base/folder/network.png

where "/orgfile/base/folder" is the dirname of the full path of my
.org file (e.g. something like /orgfile/base/folder/file.org).

So org-ditaa apparently somewhere still tries to set a work directory
(or so?) after the org-ditaa-jar-option part. I'm not exactly sure
which code version the current Emacs Flatpak has, and I don't know how
to look (I'm not *that* much of a Flatpak nerd :-p ) But if I had to
bet, I'd assume it's a fairly recent one.

Cheers,
Florin.

PS: I'm not sure how to read this in gmane. I went to gmane.io, but
all I see is a green text and two links -- a kind-of blog entry with
gmane's history, and an admin interface. None of those looks like I'd
be able to browse the mailing list. Apparently I need to do it via
NNTP?...

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

Re: org-ditaa woes

[Max Nikulin]

On 21/10/2023 04:39, Florin Boariu wrote:
>    $ flatpak-spawn --host toolbox run /usr/bin/ditaa --help

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?

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 exactly sure
> which code version the current Emacs Flatpak has, and I don't know how
> to look

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

> PS: I'm not sure how to read this in gmane.
> […] Apparently I need to do it via
> NNTP?...

Yes, add news.gmane.io news server and subscribe to gmane.emacs.orgmode. 
You may send replies using your regular SMTP mail account.

Re: org-ditaa woes

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]


Florin Boariu <florin.om@rootshell.ro> writes:
> Replying to Arne's comment:
>
>> In my current source I see [...]
>>
>> (use C-h v org-babel-ditaa-java-cmd to see the value of the java
>> executable — you can then customize this to use a different command)
>
> As far as I understand that part of code it still kind-of assumes that
> I'm using a command line of type "java -jar ditaa.jar ...", just with
> more flexibility in choosing which "java" command I'm using, right?

Yes, it does. ob-plantuml already migrated to allow a regular command,
but ob-ditaa still only enables using the jar directly.

That is something which would be nice to fix — and ob-plantuml should
show the path forward.

> I've just tried setting org-babel-ditaa-java-cmd to "/usr/bin/ditaa",
> and org-ditaa-jar-option to "", but now the error is something like:
>
>> /usr/bin/ditaa   /orgfile/base/folder  \
>>      /tmp/babel-0YxwcE/ditaa-NyIQwH \
>>      /orgfile/base/folder/network.png
>
> where "/orgfile/base/folder" is the dirname of the full path of my
> .org file (e.g. something like /orgfile/base/folder/file.org).
>
> So org-ditaa apparently somewhere still tries to set a work directory
> (or so?) after the org-ditaa-jar-option part. I'm not exactly sure
> which code version the current Emacs Flatpak has, and I don't know how
> to look (I'm not *that* much of a Flatpak nerd :-p ) But if I had to
> bet, I'd assume it's a fairly recent one.

If you do the C-h v org-ditaa-jar-option command, you should normally
have a link to ob-ditaa.el in your help buffer. You can click that to
get the source.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

[TASK] Allow customizeable ditaa executable in ob-ditaa.el (was: org-ditaa woes)

[Ihor Radchenko]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

>>> In my current source I see [...]
>>>
>>> (use C-h v org-babel-ditaa-java-cmd to see the value of the java
>>> executable — you can then customize this to use a different command)
>>
>> As far as I understand that part of code it still kind-of assumes that
>> I'm using a command line of type "java -jar ditaa.jar ...", just with
>> more flexibility in choosing which "java" command I'm using, right?
>
> Yes, it does. ob-plantuml already migrated to allow a regular command,
> but ob-ditaa still only enables using the jar directly.
>
> That is something which would be nice to fix — and ob-plantuml should
> show the path forward.

+1
This is a relatively simple task.
One can indeed use ob-plantuml as a reference to extend ob-ditaa.
Patches welcome!

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org-ditaa woes

[Florin Boariu]

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

Re: org-ditaa woes

[Florin Boariu]

I heard everybody referencing "org-plantuml" several times here :-)

I gave it a try, and, for reference, this is how my "org-plantuml" is
being set up in my case:

> (org-babel-do-load-languages 'org-babel-load-languages '(
>    [...]
>    (plantuml . t)
>    [...]
>  ))
>
> (setq org-plantuml-exec-mode 'plantuml)
> (setq org-plantuml-executable-path "flatpak-spawn --host toolbox run /usr/bin/plantuml")
>

And with this as a document:

> #+begin_src plantuml :file kmc3net.png
>   bob -> alice: moo
> #+end_src

it works as expected 🤷 (i.e. provides a [[file::kmc3net.png]] link,
which actually leads to a newly created file with the correct
contents).

Cheers,
F.

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

Re: org-ditaa woes

[Max Nikulin]

On 23/10/2023 18:18, Florin Boariu wrote:
>
>> sh-5.1$ flatpak-spawn --host toolbox run /usr/bin/ditaa /tmp/foo.txt 
>> -o /tmp/foo.png

thanks

> I really _need_ to generically execute a command.

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,
- 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.


2.
- 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 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). 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 upstream.

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

#!/bin/sh
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.

Re: org-ditaa woes

[Florin Boariu]

Hello,

>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
works.

It doesn't:

     sh-5.1$ flatpak-spawn --host toolbox run java -jar /usr/share/java/ditaa.jar
     Error: Unable to initialize main class org.stathissideris.ascii2image.core.CommandLineConverter
     Caused by: java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException

🤷

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

>2.
>- 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
>upstream.

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
>
>#!/bin/sh
>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
     /usr/bin/git
     sh-5.1$ which gcc
     /usr/bin/gcc
     sh-5.1$

(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 (/app/bin:/usr/bin:/var/home/florin/.var/app/org.gnu.emacs/data/node/bin:/var/home/florin/.var/app/org.gnu.emacs/data/cargo/bin:/var/home/florin/.var/app/org.gnu.emacs/data/python/bin)

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 )

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

Re: org-ditaa woes

[Ihor Radchenko]

Florin Boariu <florin.om@rootshell.ro> writes:

> 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

Writing a patch is also welcome.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org-ditaa woes

[Leo Butler]

On Tue, Oct 24 2023, Ihor Radchenko <yantar92@posteo.net> wrote:

> Florin Boariu <florin.om@rootshell.ro> writes:
>
>> 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
>
> Writing a patch is also welcome.

I am looking at ob-ditaa. Patching it looks within my reach.

Is there no testsuite for it?

Leo

Re: org-ditaa woes

[Max Nikulin]

On 26/10/2023 02:00, Leo Butler wrote:
> I am looking at ob-ditaa. Patching it looks within my reach.
> 
> Is there no testsuite for it?

Unfortunately there is only a couple of examples at

https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-ditaa.html

Re: org-ditaa woes

[Ihor Radchenko]

Leo Butler <Leo.Butler@umanitoba.ca> writes:

>> Writing a patch is also welcome.
>
> I am looking at ob-ditaa. Patching it looks within my reach.
>
> Is there no testsuite for it?

No test suite. But you may refer to testing/lisp/test-ob-jave.el to see
how to write simple ob-* tests.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: org-ditaa woes

[Leo Butler]

[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

On Tue, Oct 24 2023, Max Nikulin <manikulin@gmail.com> wrote:

> On 23/10/2023 18:18, Florin Boariu wrote:
>>
>>> sh-5.1$ flatpak-spawn --host toolbox run /usr/bin/ditaa
>>> /tmp/foo.txt -o /tmp/foo.png
>
> thanks
>
>> I really _need_ to generically execute a command.
>
> 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,
> - 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.
>
>
> 2.
> - 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 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). 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 upstream.
>
> 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
>
> #!/bin/sh
> 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.

Florin,

Max is right, there are work-arounds possible, although a bit different
from what he suggests. The attached org file shows how to do what you
want using the existing ob-ditaa.el code. I have also attached the
exported html document with the image created.

Tell us if it works for the version of Org that you are using.

Leo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ob-doc-ditaa-script.org --]
[-- Type: text/x-org; name="ob-doc-ditaa-script.org", Size: 1974 bytes --]

#+author: Leo Butler
#+title: Executing ditaa from a script

* Executing =ditaa= from a script

Org assumes that =ditaa= is run as a java jar file.  Users may need to
use a script to run =ditaa=.  This example shows how.

First, set ~org-babel-ditaa-java-cmd~ and ~org-ditaa-jar-option~ to
empty strings and ~org-ditaa-jar-path~ to the script's path; here, it
is =/usr/bin/ditaa=.  This example uses ~setq-local~ to change only
the values in this buffer.

#+name: hello-world-from-script.el.org
#+begin_src org :exports code :results replace
,#+name: hello-world-from-script.el
,#+begin_src emacs-lisp :exports none :results none
(setq-local org-babel-ditaa-java-cmd ""
	    org-ditaa-jar-option ""
	    org-ditaa-jar-path "/usr/bin/ditaa")
,#+end_src
#+end_src

#+RESULTS: hello-world-from-script.el.org
#+name: hello-world-from-script.el
#+begin_src emacs-lisp :exports none :results none
(setq-local org-babel-ditaa-java-cmd ""
	    org-ditaa-jar-option ""
	    org-ditaa-jar-path "/usr/bin/ditaa")
#+end_src

Second, in the =ditaa= code-block, set the header argument =:java= to
the empty string =""=.  The =:cmdline= header argument can be used to
pass command-line options to =ditaa= via the script.

#+name: hello-world-from-script.org
#+begin_src org :exports code :results replace
,#+name: hello-world-from-script
,#+begin_src ditaa :file images/hello-world-from-script.png :java "" :cmdline -r -e UTF-8
+----------------+
|                |
| Hello World    |
| from a script! |
|                |
+----------------+
,#+end_src
#+end_src

#+RESULTS: hello-world-from-script.org
#+name: hello-world-from-script
#+begin_src ditaa :file images/hello-world-from-script.png :java "" :cmdline -r -e UTF-8
+----------------+
|                |
| Hello World    |
| from a script! |
|                |
+----------------+
#+end_src

#+RESULTS: hello-world-from-script
[[file:images/hello-world-from-script.png]]

[-- Attachment #3: ob-doc-ditaa-script.html --]
[-- Type: text/html, Size: 11078 bytes --]

[-- Attachment #4: hello-world-from-script.png --]
[-- Type: image/png, Size: 3314 bytes --]

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Leo Butler]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

On Sat, Oct 21 2023, Ihor Radchenko <yantar92@posteo.net> wrote:

> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>>>> In my current source I see [...]
>>>>
>>>> (use C-h v org-babel-ditaa-java-cmd to see the value of the java
>>>> executable — you can then customize this to use a different command)
>>>
>>> As far as I understand that part of code it still kind-of assumes that
>>> I'm using a command line of type "java -jar ditaa.jar ...", just with
>>> more flexibility in choosing which "java" command I'm using, right?
>>
>> Yes, it does. ob-plantuml already migrated to allow a regular command,
>> but ob-ditaa still only enables using the jar directly.
>>
>> That is something which would be nice to fix — and ob-plantuml should
>> show the path forward.
>
> +1
> This is a relatively simple task.
> One can indeed use ob-plantuml as a reference to extend ob-ditaa.
> Patches welcome!

While I was reviewing the documentation, ob-doc-ditaa.org, and the
source, ob-ditaa.el, I realized that there is a simple way to run a
script file instead of a jar file. The documentation patch includes such
an example.

Leo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-contrib-babel-languages-ob-doc-ditaa.org-update-.patch --]
[-- Type: text/x-diff; name="0001-org-contrib-babel-languages-ob-doc-ditaa.org-update-.patch", Size: 10308 bytes --]

From 6424527dde6e487ce55dddae1260df3d84c2775e Mon Sep 17 00:00:00 2001
From: Leo Butler <leo.butler@umanitoba.ca>
Date: Thu, 26 Oct 2023 20:49:41 -0500
Subject: [PATCH] * org-contrib/babel/languages/ob-doc-ditaa.org: update
 documentation

* org-contrib/babel/languages/ob-doc-ditaa.org: Add a subsection that
documents the four DEFCUSTOM variables.  Modify the existing examples
so that the org code that is exported also creates the code-blocks
that are executed.  Add a subsection that documents how to use those
customization variables in order to run ditaa from a script, not
necessarily as a jar file.

* org-contrib/babel/languages/images/hello-world-from-script.png:
This is a new file created by the new example.

Ref: https://list.orgmode.org/ZTEML8zWrB6kQflk@toolbox/T/
---
 .../images/hello-world-from-script.png        | Bin 0 -> 3314 bytes
 org-contrib/babel/languages/ob-doc-ditaa.org  |  86 ++++++++++++++++--
 2 files changed, 77 insertions(+), 9 deletions(-)
 create mode 100644 org-contrib/babel/languages/images/hello-world-from-script.png

diff --git a/org-contrib/babel/languages/images/hello-world-from-script.png b/org-contrib/babel/languages/images/hello-world-from-script.png
new file mode 100644
index 0000000000000000000000000000000000000000..8a039e1bad997ebd31d8906cc1d1f234e9159e09
GIT binary patch
literal 3314
zcmchacQjn<8pcV8kQk!(8ex<mPL7sfbTgui5)m0e)M%q-Bzo^9Lq-dR5zz@5(FNfQ
zu5Ltv7$o5k!5C$fyR+`O>#lXzy7#|(_gZ`J_5HEm_xslOd!FyviDo7S%uIYtG&D5K
zMuxg@;Qbl6Q!btZo|w00qBJy@-x=vbET14Y3*C)5iNbLVb~e)IxEefsds>|opv_k9
zPE8Q{37)&3Qy<^oFLUp*Bu9@QK)ld=%yQFiy31UTQ#eu$Q!31msn~>zST1r@!fNBf
zS-z@s3&>ZV?cgZ}RmAdjI9I7l>BXY|Xo3G0go9r+tK_@P#ltZ(sF+|g+?ss{Qi9f1
zlaj~;L5<3y;cRQg|BqoQJ+2+OtZ!*)iT9r8a16+BUg6^<!p5%JLJ3N)e>*rj@}6(K
zDI)_*Hcnw`OtBMR9!L{>N~P3Hd(>1^R8&?@JRVnRsviO4`W?6T_f3tBrySXoB2uV_
zht7{4X+>mZWi>W7mZM(Ndzyfq939JzbFuVSzlw^9iK(fnNlLydF8(r-ue`dt8luV<
z$yK9@O98I*bmBR-T~=;xZa%({{U7ri8=g-R4N%U`xCIthxA8m+LU(sJ1B;LwZ6Ycn
z?Lk}69U~)%sIoF1m=a?&?pGP|&d&R>8lctE-k(GvAtBe%mmNWybG`8_ySuwE7;G<0
zMJIWt0N&c#YW*qp+E-dsFcPVX+Ii&Xx3l>Pzq_;Zla5GTx-4hw4}C4wJf84Ti;^yM
zJLL5EkW3C3mQ7Ah21=Cvj<%jqMukh^av>BJVT}R|29uMMlbvm4V^gu;%iCPil-2nM
zRR=tBxlveHxF{ndBQGy6H`l$vhWzhe3#!q98)hQWb%>4$>Qc&_nXS>{%1H^@B@Tdr
z74A{QWDea~`p=N`PQl;0Pkt>;*QmUIdNygc<>26OU|v>M_T7|+FWOM`$<K#&QQRV+
z$;nBiir>m$@clLSJTxsWZEbCBe}6y8m;8M^skKT^z<Z&cH~v1}yQZV~%5PKZxH9yf
zoB4~13Mo3x;2#1691iF0?X6<h;25hy9Z_EV4N@8xQlx@(WXCoK8H=tabIX^T6t1tX
zPS@PWXUp6@rEYa$J4L}on&BE=b4_W|09Ue7QmlJX_TeX-J<48lF*~uBxXnJq_Vo0S
zHYAIlk(QRs5r`impd;JPXNNvrCo}K-zioA$A*S3qbb27s7eoi!QM=bnUmAm%r6jPa
zJc{SyArQz3b>F~Yy3z`JPX``$xcb74vi7PdiPF+uSqUvT2k@;8AbFL*uk5Xh`jEo=
zq?ntF%f;1o*>_{MA#J%>-p9x1SUuqT*zBy0xp+ujb@j${6*u4hpG0{Dg?a!oCY<Lq
ze4Q1J=m_C-K8U<gpanBEHAPx=z{|_au_xV;=N0E5nGU^iOFv2d$!B|Iooe>>_Tk~-
z=z&yzA`bQ<nt=s7vNrij@r|y-$<f}go@hn5hhp=>^Q<gikM0QC7J^4JWo^=+1YKiG
z7#kZ?$Tlz4cZYxI?*|8VM^Dd0pcy~{TG0})oP?vBk7vI45^Em-jo5^QYAenwUC+JY
zOjsUBM;<JvYu4V!gJQc*kA{!}<XF+MF!FTBBHl+hPwxI(<EhbHrGNAY5nk*%J5?v#
z4k5F4GARr--4wxPJlQ7oV-bT*!CMHV6f10lng91Mi-0IfFKjD%INs71*dFQuk!JU0
z#*7X(@ry}Ehr8b_py#2eRRSkkM_XH3TDtF^@u_YJ0z5e}fzD&7pv>MeG2t4advX1N
zHtsvern%Bnis!9?ljGyDOt)o`wDaJ80%N9(Wj(0`eE~gTy=(5MrA3n?V&iX&QGiSl
zWpE?jk>_w`2gkdkdL8=r?&Y?%shb3TAESL=;xhX3b`oK(`Ej!gb3al<LbtEDs^U^%
zXDIcp&*Dosp9QqN65z{`$KT&yryTGg-B2C4t!xfz_v_)oL9xru${#2c3cDaQY(L&l
zv=5g9Z7p`mm)#25z|54FsDR3vUh8=J`YKpE!CqXSf9u7M^Q?ihi9^7N0l&QaLgo&z
ze9S^1K#|2O6Oww?4E>BUW&<RkGIrVvn{;FahaW64*hS%nx$U1J*Cr%R+}C<wh<ARg
zc{d-EB^M+#H8s`LY^k6J&*ozBq_!H{+ZQtZj>u~*D}9OVN9-T8Wj}1qw@HGwKEEri
z2*0~DZ(SoKZg@B(-<4p>9Er!{@0`Tw;h6_|;tBzsU{kxg!U4}D*4z&UiWC<Yg9O!L
zVq;HsM>Q#ek-!u~_onY^XlU?cyN={JH`oL)|L!@<%E}r+T?1H16IA!~AS$^GcT2S3
z8=M9-LXW1b7X{ZfikMhf25zkYWc`@H!R+h=q|*gdqeMu~((B*s9nTE9!cLkNQX{XF
z9RsS%P}Mt`(?8xn@mlxnMb<ko#3K-hqEJe1&K97LL^9xUwnXCBk^GXq3iDDCMLyXF
zty8BPxk|1adnmOKvKt_r**KzD=g``Gn{sP+Xwn0(z%4ULTz)=(3I{dc_u|=1oqamY
zSH)$Rr`_S@?WdHTRTvUa*?&mGao&*ei`ez?)4oKrJD=i~1A5bD8`K@%)1eiMvB%$v
z!m%k3bKNm1Ik{%r8mX19U!~XgBPp)S%gg4fNRn<9Q`x&`hmF`y-aab{2?;Fj2S_iq
z0}UPF#sJQyj~dF6lLA%_Z+QCbMRqp$CVz2CjH4xZ6ThUgP`^wfiFI-fz;&ud2M4uK
z2S1lcY^jCn!H(6OZ6go>)Xh;YPEKat8+3bsq4XcKY|%EzIgMlWC?lSMKg_0PVTo_1
z*I9^R$#Evo2$$#A?o5DEBOP!}XF_$E{6RnK^*b=#ORna32`ej)EVUh{(uFlUYtb~~
zV&z#R)BO^I?ZTFs=C~iAz?)u{mD9pMgu{;`FD{1e7uINi6^**ZOx1t8P@d5U)GC1T
zva?4M0A<X1Sa+&{8xpQiXX>^60t5Rmv*BZ0La7wa^esu#mu~*h0XRwe){(h>Fm%KR
zn^-7em>o3zC$X-1-ZZX<13t%xcNln$W@KcnAd|_LnVC1IUb9<&R|5xcEo?3=Mbh5^
z)MNWz)R@{=D=ZsO@6qFL?^#gwG(Hg5*QhTWF!$Cg|M~OiBLH4fy=jrg@`u#6u#+Re
z&bJRf*nQMUqg6;or+%zowuD9uNad{0w*@bDg`Y*yUkZR<laQdNr|*Fs#Lzb$P%VKI
zIw>Kc+n=jyXK>I^@zG3&P9YjYqibMLDsOD6D9N>lS&NH_X=!WQU!T6jg2XT__xAQa
zF6B8FZRoBbA`#~hTH{`fz5x#wxXFoz>q|-CuKN8`>F6v&2He$&|2`CbjRwxs>7bHC
zR7G`l01}yL4waXe-yXW&=gGmr0d&?O#Kh1U=H}*tlhKipk)&Y8gpVx%aYaQ%DR6y#
z{SN~JkAYk>+vq%$A*z!RYM7gs#{`z+O8#f|0mw-_i-^S}dF;s}_4M=vHJ+&`Dk{p!
z$;rr6)z_PC#Va*MjDRH;1OW18!qhV{F&GSwtYpx}ED|{5cfXCkdiBcH)fI?Wf1dcp
zan-Bh=p;=Fer|7nY;vFM%{xOB@nrAp>{Q*YyMC{+Z*tPVKZz5GL;@@ro0tH;8iYVB
ze8T(e`2i8?^DrC;Jis>S>FPclv`iS^rcgkPjE9HcikzIBHZ@rYqoeVRA*u!Aa5!n+
z!qO6*pZ^rFCp4Pl^XfKmSOF#i{weCHn{jW2`<{MnCUQmaWBhpqh<v;fkU<FqXv!yG
zhcQ-PP8HhiTYPEX4AW)5>9a{_66+eg;g^~szBQ;J5b;+B>#FG0d}SYBS5;M2US3{h
zpM_%}eOOpn)Ljve8vfT8VeD~#taD{IR#sM4S67#n(Iszl%Ok$%ziDi|VI{=oBs!6F
zEH*TF^F~^`IMr9HPEXto0<N->mywpPww8%Qw)-gbc5ily>C@%vg=PNA%mxejE{_6X
qFe5|u|7~zz&&*;q`m06S8LeG+hGOd>J{tI!p)t}k(XG{f81;7r&UPvQ

literal 0
HcmV?d00001

diff --git a/org-contrib/babel/languages/ob-doc-ditaa.org b/org-contrib/babel/languages/ob-doc-ditaa.org
index 0ae949c2..66f7d4ad 100644
--- a/org-contrib/babel/languages/ob-doc-ditaa.org
+++ b/org-contrib/babel/languages/ob-doc-ditaa.org
@@ -57,6 +57,14 @@ Activate evaluation of =ditaa= source code blocks by adding =ditaa= to
      '((ditaa . t))) ; this line activates ditaa
 #+END_SRC
 
+** Customization Options
+Org needs to know a few things about =ditaa= and the =java= executable in order to function. The following is a list of variables that can be customized.
+
+- org-ditaa-jar-path :: The path to the =ditaa= jar file.
+- org-babel-ditaa-java-cmd :: The name or path to the Java executable used to run the =ditaa= jar file.
+- org-ditaa-eps-jar-path :: The path to the =ditaaeps= jar file. [[https://ditaa-addons.sourceforge.net/][DitaaEps]] is maintained as part of the [[https://ditaa-addons.sourceforge.net/][ditaa-addons]] project.
+- org-ditaa-jar-option :: The prefix used before the =ditaa= jar path. The default is =-jar=.
+
 * Babel Features for ditaa Code Blocks
 ** Header Arguments
    - file :: =ditaa= source code blocks require that an output file be specified
@@ -67,8 +75,13 @@ Activate evaluation of =ditaa= source code blocks by adding =ditaa= to
 ** Result Types
 =Ditaa= source code blocks return a link to a [[http://www.libpng.org/pub/png/][png]] bitmap file.
 * Examples of Use
+** Hello World
 The obligatory Hello World! example in =ditaa=:
-#+BEGIN_EXAMPLE
+
+#+NAME: hello-world.org
+#+BEGIN_SRC org :exports code :results replace
+,#+NAME: hello-world
+,#+HEADER: :exports results
 ,#+BEGIN_SRC ditaa :file images/hello-world.png
 +--------------+
 |              |
@@ -76,9 +89,11 @@ The obligatory Hello World! example in =ditaa=:
 |              |
 +--------------+
 ,#+END_SRC
-#+END_EXAMPLE
+#+END_SRC
 
-#+header: :exports results
+#+RESULTS: hello-world.org
+#+NAME: hello-world
+#+HEADER: :exports results
 #+BEGIN_SRC ditaa :file images/hello-world.png
 +--------------+
 |              |
@@ -87,23 +102,29 @@ The obligatory Hello World! example in =ditaa=:
 +--------------+
 #+END_SRC
 
-#+RESULTS:
+#+RESULTS: hello-world
 [[file:images/hello-world.png]]
+** Passing command-line options to =ditaa=
 
 Now, round all corners by passing =ditaa= the =-r,--round-corners=
 command line switch.
 
-#+BEGIN_EXAMPLE
-#+BEGIN_SRC ditaa :file images/hello-world-round.png :cmdline -r
+#+NAME: hello-world-round.org
+#+BEGIN_SRC org :exports code :results replace
+,#+NAME: hello-world-round
+,#+HEADER: :exports results
+,#+BEGIN_SRC ditaa :file images/hello-world-round.png :cmdline -r
 +--------------+
 |              |
 | Hello World! |
 |              |
 +--------------+
+,#+END_SRC
 #+END_SRC
-#+END_EXAMPLE
 
-#+header: :exports results
+#+RESULTS: hello-world-round.org
+#+NAME: hello-world-round
+#+HEADER: :exports results
 #+BEGIN_SRC ditaa :file images/hello-world-round.png :cmdline -r
 +--------------+
 |              |
@@ -112,6 +133,53 @@ command line switch.
 +--------------+
 #+END_SRC
 
-#+RESULTS:
+#+RESULTS: hello-world-round
 [[file:images/hello-world-round.png]]
 
+** Executing =ditaa= from a script
+
+Org assumes that =ditaa= is run as a java jar file.  Users may need to
+use a script to run =ditaa=.  This example shows how.
+
+First, set ~org-babel-ditaa-java-cmd~ and ~org-ditaa-jar-option~ to
+empty strings and ~org-ditaa-jar-path~ to the script's path; here, it
+is =/usr/bin/ditaa=.  This example uses ~setq-local~ to change only
+the values in this buffer.
+
+#+NAME: hello-world-from-script.el.org
+#+BEGIN_SRC org :exports code :results replace
+,#+NAME: hello-world-from-script.el
+,#+BEGIN_SRC emacs-lisp :exports none :results none
+(setq-local org-babel-ditaa-java-cmd ""
+	    org-ditaa-jar-option ""
+	    org-ditaa-jar-path "/usr/bin/ditaa")
+,#+END_SRC
+#+END_SRC
+
+#+RESULTS: hello-world-from-script.el.org
+#+NAME: hello-world-from-script.el
+#+BEGIN_SRC emacs-lisp :exports none :results none
+(setq-local org-babel-ditaa-java-cmd ""
+	    org-ditaa-jar-option ""
+	    org-ditaa-jar-path "/usr/bin/ditaa")
+#+END_SRC
+
+Second, in the =ditaa= code-block, set the header argument =:java= to
+the empty string =""=.  The =:cmdline= header argument can be used to
+pass command-line options to =ditaa= via the script.
+
+#+NAME: hello-world-from-script.org
+#+BEGIN_SRC org :exports code :results replace
+,#+name: hello-world-from-script
+,#+begin_src ditaa :file images/hello-world-from-script.png :java "" :cmdline -r -e UTF-8
++----------------+
+|                |
+| Hello World    |
+| from a script! |
+|                |
++----------------+
+,#+END_SRC
+#+END_SRC
+
+#+RESULTS: hello-world-from-script
+[[file:images/hello-world-from-script.png]]
-- 
2.42.0

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Max Nikulin]

On 09/11/2023 10:17, Leo Butler wrote:
> While I was reviewing the documentation, ob-doc-ditaa.org, and the
> source, ob-ditaa.el, I realized that there is a simple way to run a
> script file instead of a jar file.

diff --git a/lisp/ob-ditaa.el b/lisp/ob-ditaa.el
index fa864c7bc..4a2b09cd9 100644
--- a/lisp/ob-ditaa.el
+++ b/lisp/ob-ditaa.el
@@ -100,11 +100,13 @@ (defun org-babel-execute:ditaa (body params)
                      "epstopdf"
                      " " eps-file
                      " -o=" (org-babel-process-file-name out-file))))
+        (jar (org-string-nw-p (if eps org-ditaa-eps-jar-path 
org-ditaa-jar-path)))
          (cmd (concat org-babel-ditaa-java-cmd
-                     " " java " " org-ditaa-jar-option " "
-                     (shell-quote-argument
-                      (expand-file-name
-                       (if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
+                     " " java
+                     (and jar
+                          (concat
+                            " " org-ditaa-jar-option " "
+                            (shell-quote-argument (expand-file-name jar))))
                       " " cmdline
                       " " (org-babel-process-file-name in-file)
                       " " (if pdf-cmd

should allow to set :java to

     flatpak-spawn --host toolbox run /usr/bin/ditaa

without abusing of org-ditaa-jar-path. Untested.

It is better to avoid obstacles than to document them.

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Leo Butler]

On Thu, Nov 09 2023, Max Nikulin <manikulin@gmail.com> wrote:

> On 09/11/2023 10:17, Leo Butler wrote:
>> While I was reviewing the documentation, ob-doc-ditaa.org, and the
>> source, ob-ditaa.el, I realized that there is a simple way to run a
>> script file instead of a jar file.
>
>
> It is better to avoid obstacles than to document them.

Ok, I figured that would be the response.

> diff --git a/lisp/ob-ditaa.el b/lisp/ob-ditaa.el
> index fa864c7bc..4a2b09cd9 100644
> --- a/lisp/ob-ditaa.el
> +++ b/lisp/ob-ditaa.el
> @@ -100,11 +100,13 @@ (defun org-babel-execute:ditaa (body params)
>                      "epstopdf"
>                      " " eps-file
>                      " -o=" (org-babel-process-file-name out-file))))
> +        (jar (org-string-nw-p (if eps org-ditaa-eps-jar-path
> org-ditaa-jar-path)))
>          (cmd (concat org-babel-ditaa-java-cmd
> -                     " " java " " org-ditaa-jar-option " "
> -                     (shell-quote-argument
> -                      (expand-file-name
> -                       (if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
> +                     " " java
> +                     (and jar
> +                          (concat
> +                            " " org-ditaa-jar-option " "
> +                            (shell-quote-argument (expand-file-name jar))))
>                       " " cmdline
>                       " " (org-babel-process-file-name in-file)
>                       " " (if pdf-cmd
>
> should allow to set :java to
>
>     flatpak-spawn --host toolbox run /usr/bin/ditaa
>
> without abusing of org-ditaa-jar-path. Untested.

Doesn't this abuse the `java' header argument, which is intended to pass
arguments to the java runtime?

I think that it would be best to implement the change to mirror that
done in ob-plantuml, as Ihor suggested earlier. But, ob-plantuml uses a
customization switch: `org-plantuml-exec-mode'. Its documentation reads:

  Method to use for PlantUML diagram generation.
  `jar' means to use java together with the JAR.
  The JAR can be configured via `org-plantuml-jar-path'.
  
  `plantuml' means to use the PlantUML executable.
  The executable can be configured via `org-plantuml-executable-path'.
  You can also configure extra arguments via
  `org-plantuml-executable-args'.[fn:1] 

My reading of the documentation and ob-plantuml.el is that it is not
possible to use the `java' header argument in the way you propose for
ob-ditaa.el.

Leo

[fn:1] (Aside: `org-plantuml-executable-args' should be `org-plantuml-args';
Ihor missed it when he made the change in commit b5f0efc049).

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Ihor Radchenko]

Leo Butler <Leo.Butler@umanitoba.ca> writes:

> [fn:1] (Aside: `org-plantuml-executable-args' should be `org-plantuml-args';
> Ihor missed it when he made the change in commit b5f0efc049).

Now fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5c82e1e1d

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Ihor Radchenko]

Leo Butler <Leo.Butler@umanitoba.ca> writes:

> While I was reviewing the documentation, ob-doc-ditaa.org, and the
> source, ob-ditaa.el, I realized that there is a simple way to run a
> script file instead of a jar file. The documentation patch includes such
> an example.

Org cannot support every possible feature. And even if we do want to add
certain features in future (like supporting ditaa executable herein), it
does not mean that we have to rush them by any cost.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Max Nikulin]

On 10/11/2023 10:19, Leo Butler wrote:
> On Thu, Nov 09 2023, Max Nikulin wrote:
> 
>> diff --git a/lisp/ob-ditaa.el b/lisp/ob-ditaa.el
[...]
>> should allow to set :java to
>>
>>      flatpak-spawn --host toolbox run /usr/bin/ditaa
>>
>> without abusing of org-ditaa-jar-path. Untested.
> 
> Doesn't this abuse the `java' header argument, which is intended to pass
> arguments to the java runtime?

or `org-babel-ditaa-java-cmd'. My point is that requirement of non-empty 
`org-ditaa-jar-path' confused Florin to the degree when workarounds 
looked impossible. Notice that setting

     org-ditaa-jar-path "/usr/bin/ditaa"

still requires spreading of "flatpack-spawn ..." over 
`org-babel-ditaa-java-cmd', :java, and `org-ditaa-jar-option'. 
fortunately some of these options may be sent empty and other will not 
quote spaces, etc. Whole "flatpack-spawn ... ditaa" command can not be 
put to `org-ditaa-jar-path'

> I think that it would be best to implement the change to mirror that
> done in ob-plantuml, as Ihor suggested earlier.

Agree. I appreciate consistency in treatment of similar cases.

I am not sure in the following idea. Perhaps a concept of "launcher" (or 
"runner") may be introduced. Launchers may be stacked. So for a jar file 
launcher is "java @:java -jar" that may be combined with "toolbox run" 
and "flatpak-spawn --host" launchers.

> My reading of the documentation and ob-plantuml.el is that it is not
> possible to use the `java' header argument in the way you propose for
> ob-ditaa.el.

Since nobody has proposed a patch for ob-ditaa, I decided that making a 
workaround easier is an improvement.

      #+property: header-args:ditaa :java ...

would not affect ob-plantuml.

P.S. I am unsure what is proper balance between flexibility/convenience 
and security. A file downloaded from net should not be able to change 
executables and their options without consent from the user. 
Unfortunately attempts to suppress at least shell expansion will lead to 
more verbose configuration.

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Leo Butler]

On Fri, Nov 10 2023, Ihor Radchenko <yantar92@posteo.net> wrote:

> Leo Butler <Leo.Butler@umanitoba.ca> writes:
>
>> While I was reviewing the documentation, ob-doc-ditaa.org, and the
>> source, ob-ditaa.el, I realized that there is a simple way to run a
>> script file instead of a jar file. The documentation patch includes such
>> an example.
>
> Org cannot support every possible feature.

Agreed.

> And even if we do want to add certain features in future (like
> supporting ditaa executable herein), it does not mean that we have to
> rush them by any cost.

Ihor, I don't understand that sentence.

The *documentation* patch was intended to show that ob-ditaa did not
need to be changed. A user can already run ditaa from a script file by
setting the customization variables appropriately (or, inappropriately,
as Max said ;-) ).

Leo

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Leo Butler]

On Fri, Nov 10 2023, Max Nikulin <manikulin@gmail.com> wrote:

> On 10/11/2023 10:19, Leo Butler wrote:
>> On Thu, Nov 09 2023, Max Nikulin wrote:
>> 
>>> diff --git a/lisp/ob-ditaa.el b/lisp/ob-ditaa.el
> [...]
>>> should allow to set :java to
>>>
>>>      flatpak-spawn --host toolbox run /usr/bin/ditaa
>>>
>>> without abusing of org-ditaa-jar-path. Untested.
>> 
>> Doesn't this abuse the `java' header argument, which is intended to pass
>> arguments to the java runtime?
>
> or `org-babel-ditaa-java-cmd'. My point is that requirement of non-empty 
> `org-ditaa-jar-path' confused Florin to the degree when workarounds 
> looked impossible. Notice that setting
>
>      org-ditaa-jar-path "/usr/bin/ditaa"
>
> still requires spreading of "flatpack-spawn ..." over 
> `org-babel-ditaa-java-cmd', :java, and `org-ditaa-jar-option'. 
> fortunately some of these options may be sent empty and other will not 
> quote spaces, etc. Whole "flatpack-spawn ... ditaa" command can not be 
> put to `org-ditaa-jar-path'

Hi Max,

Let me back up for a second: I wrote in the documentation patch

"Users may need to use a script to run ditaa."

That is a very circumspect statement. That is not saying that we can
throw any command at ob-ditaa and it will work.

>
>> I think that it would be best to implement the change to mirror that
>> done in ob-plantuml, as Ihor suggested earlier.
>
> Agree. I appreciate consistency in treatment of similar cases.

I am glad we agree. Now let me tell you my dilemma: a while ago, I
suggested a patch to implement similar functionality for ob-maxima. The
patch used customization variables, much like ob-plantuml does. Ihor's
feedback was that this was not a good approach (too much room for
accidental breakage, etc.). Eventually, the patch was amended to acheive
the same goals using new header arguments.

So, now, in my opinion, consistency would dictate that we re-visit the
changes made to ob-plantuml, re-fashion them and do something similar
with ob-ditaa. Except, users have likely become accustomed to using
ob-plantuml as it is...

Thoughts?

>
> I am not sure in the following idea. Perhaps a concept of "launcher" (or 
> "runner") may be introduced. Launchers may be stacked. So for a jar file 
> launcher is "java @:java -jar" that may be combined with "toolbox run" 
> and "flatpak-spawn --host" launchers.
>
>> My reading of the documentation and ob-plantuml.el is that it is not
>> possible to use the `java' header argument in the way you propose for
>> ob-ditaa.el.
>
> Since nobody has proposed a patch for ob-ditaa, I decided that making a 
> workaround easier is an improvement.

I am not in favour of a band-aid, it will hand-cuff us in the future.

I explained above why I haven't proposed a patch to ob-ditaa, yet.

Best,
Leo

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Ihor Radchenko]

Leo Butler <Leo.Butler@umanitoba.ca> writes:

> I am glad we agree. Now let me tell you my dilemma: a while ago, I
> suggested a patch to implement similar functionality for ob-maxima. The
> patch used customization variables, much like ob-plantuml does. Ihor's
> feedback was that this was not a good approach (too much room for
> accidental breakage, etc.). Eventually, the patch was amended to acheive
> the same goals using new header arguments.
>
> So, now, in my opinion, consistency would dictate that we re-visit the
> changes made to ob-plantuml, re-fashion them and do something similar
> with ob-ditaa. Except, users have likely become accustomed to using
> ob-plantuml as it is...
>
> Thoughts?

Let me clarify.

For ob-maxima, my main concern was that we _need_ certain header
arguments to parse the output of Maxima. So, those _required_ header
arguments should be hard-coded and not customizeable. Other header
arguments may be customizeable (via header args or defcustom; header
args is more flexible).

This is not the case for ob-plantuml - the default -headless argument
may be safely removed; it just makes loading java faster.


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Ihor Radchenko]

Leo Butler <Leo.Butler@umanitoba.ca> writes:

>> And even if we do want to add certain features in future (like
>> supporting ditaa executable herein), it does not mean that we have to
>> rush them by any cost.
>
> Ihor, I don't understand that sentence.
>
> The *documentation* patch was intended to show that ob-ditaa did not
> need to be changed. A user can already run ditaa from a script file by
> setting the customization variables appropriately (or, inappropriately,
> as Max said ;-) ).

Let me elaborate.
The below explanation in your patch relies upon the implementation
detail in `org-babel-execute:ditaa' - how the ditaa command is called.

     +First, set ~org-babel-ditaa-java-cmd~ and ~org-ditaa-jar-option~ to
     +empty strings and ~org-ditaa-jar-path~ to the script's path; here, it
     +is =/usr/bin/ditaa=.  This example uses ~setq-local~ to change only
     +the values in this buffer.
     +
     +#+NAME: hello-world-from-script.el.org
     +#+BEGIN_SRC org :exports code :results replace
     +,#+NAME: hello-world-from-script.el
     +,#+BEGIN_SRC emacs-lisp :exports none :results none
     +(setq-local org-babel-ditaa-java-cmd ""
     +	    org-ditaa-jar-option ""
     +	    org-ditaa-jar-path "/usr/bin/ditaa")
     +,#+END_SRC
     +#+END_SRC

however, it can easily happen that we change that detail in future.
In fact, your explanation is already not correct for
:file foo.eps - org-ditaa-jar-path value is ignored in such scenario:

(cmd (concat org-babel-ditaa-java-cmd
		      " " 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)
		      " " (if pdf-cmd
			      eps-file
			    (org-babel-process-file-name out-file))))

Further, it won't help with the discussed problem -
trying
(setq org-ditaa-jar-path "flatpak-spawn --host toolbox run ditaa") will
simply fail when passed through `shell-quote-argument'.

And now imagine that we change how CMD is produced in future. (For
example, there is a WIP branch that unifies escaping command arguments
to avoid vulnerabilities). Your documentation patch may cease working
any moment, causing damage to users who tried to follow it. Or we may
have to constrain the ways we change the internal implementation details
in order to not break the existing documentation. Either way is not good
and that's why I am saying no to your proposed documentation change.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Leo Butler]

On Sat, Nov 11 2023, Ihor Radchenko <yantar92@posteo.net> wrote:

> Leo Butler <Leo.Butler@umanitoba.ca> writes:
>
>>> And even if we do want to add certain features in future (like
>>> supporting ditaa executable herein), it does not mean that we have to
>>> rush them by any cost.
>>
>> Ihor, I don't understand that sentence.
>>
>> The *documentation* patch was intended to show that ob-ditaa did not
>> need to be changed. A user can already run ditaa from a script file by
>> setting the customization variables appropriately (or, inappropriately,
>> as Max said ;-) ).
>
> Let me elaborate.
> The below explanation in your patch relies upon the implementation
> detail in `org-babel-execute:ditaa' - how the ditaa command is called.
> however, it can easily happen that we change that detail in future.

Thanks for your clarifications here and in a related email. 

> In fact, your explanation is already not correct for
> :file foo.eps - org-ditaa-jar-path value is ignored in such scenario:

You say `not correct', I say `mutatus mutandis'.

>
> (cmd (concat org-babel-ditaa-java-cmd
> 		      " " 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)
> 		      " " (if pdf-cmd
> 			      eps-file
> 			    (org-babel-process-file-name out-file))))
>
> Further, it won't help with the discussed problem -
> trying
> (setq org-ditaa-jar-path "flatpak-spawn --host toolbox run ditaa") will
> simply fail when passed through `shell-quote-argument'.

The patch says "Users may need to use a script to run ditaa." It does
not mention passing arbitrary command strings.

>
> And now imagine that we change how CMD is produced in future. (For
> example, there is a WIP branch that unifies escaping command arguments
> to avoid vulnerabilities). Your documentation patch may cease working
> any moment, causing damage to users who tried to follow it. Or we may
> have to constrain the ways we change the internal implementation details
> in order to not break the existing documentation. Either way is not good
> and that's why I am saying no to your proposed documentation change.

Ok, I have a clearer idea of how to proceed.

Leo

Formatting worg code examples (was: Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el)

[Max Nikulin]

On 09/11/2023 10:17, Leo Butler wrote:
> diff --git a/org-contrib/babel/languages/ob-doc-ditaa.org b/org-contrib/babel/languages/ob-doc-ditaa.org-#+BEGIN_EXAMPLE
> +#+NAME: hello-world.org
> +#+BEGIN_SRC org :exports code :results replace
> +,#+NAME: hello-world
> +,#+HEADER: :exports results
>   ,#+BEGIN_SRC ditaa :file images/hello-world.png
>   +--------------+
>   |              |
> @@ -76,9 +89,11 @@ The obligatory Hello World! example in =ditaa=:
>   |              |
>   +--------------+
>   ,#+END_SRC
> -#+END_EXAMPLE
> +#+END_SRC

I recall the following:

Leo Butler. Re: [TIP] Exporting Maxima results to LaTeX. Tue, 14 Feb 
2023 15:13:52 +0000. https//list.orgmode.org87wn4ks2j5.fsf@t14.reltub.ca
> 1. When editing ~org~ code blocks in an indirect buffer, it should be
> possible to recursively edit a code block. That does not appear to work
> at the moment.

What about noweb instead?

# Hide drawers when the document is opened
# to not be distracted by intermediate evaluation
# results that are duplication of original code.
#+startup: overview

# (require 'ob-org)

# Default ob-org settings are not suitable for code examples.
#+property: header-args:org :exports code :results replace :noweb yes

# Not necessary when ":exports results" is used for intermediate blocks.
# #+options: d:(not "noexport")

You may include code blocks in your documents.

# This one is actual example of code.
# It is not exported, but it may be easily edited using C-c '.
#+name: code-example-elisp
#+begin_src elisp :exports none :results silent :var a=()
   (identity a)
#+end_src

# This one is for exported document.
# To evaluate during export ":exports both" is set.
#+name: code-example-org
#+begin_src org :exports both
   ,#+name: code-example
   ,#+begin_src elisp :var a=10
   <<code-example-elisp>>
   ,#+end_src
#+end_src

:noexport:
# Hide duplicated code block inside a drawer.

# Ensure that elisp code (result of org block evaluation)
# is evaluated as well by ":exports results"
#+header: :exports results
#+results: code-example-org
#+name: code-example
#+begin_src elisp :var a=10
(identity a)
#+end_src

# Empty line above is important to keep :end:
# when the code of the org block is re-evaluated.
:end:

To get result of code evaluation
#+results: code-example
: 10
use =C-c C-c= while cursor is inside the code block.

Re: org-ditaa woes

[Leo Butler]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

On Tue, Oct 24 2023, Ihor Radchenko <yantar92@posteo.net> wrote:

> Florin Boariu <florin.om@rootshell.ro> writes:
>
>> 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
>
> Writing a patch is also welcome.

Here is a patch to the documentation. It documents currently
undocumented *features* of ob-ditaa.

I have *removed* mention of work-arounds to execute scripts. I have also
taken the liberty of re-writing the two source blocks to use org src
blocks.

I will submit a patch to ob-ditaa.el (likely in January).

Leo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-contrib-babel-languages-ob-doc-ditaa.org-update-.patch --]
[-- Type: text/x-diff; name="0001-org-contrib-babel-languages-ob-doc-ditaa.org-update-.patch", Size: 4480 bytes --]

From 15cdaff68d3ecd1348ac8b3b3998cb146e6d5345 Mon Sep 17 00:00:00 2001
From: Leo Butler <leo.butler@umanitoba.ca>
Date: Thu, 26 Oct 2023 20:49:41 -0500
Subject: [PATCH] org-contrib/babel/languages/ob-doc-ditaa.org: update
 documentation

* org-contrib/babel/languages/ob-doc-ditaa.org: Add a subsection,
Customization Options, that documents the four DEFCUSTOM variables.
Document the header arguments eps and pdf, which control how output is
created.  Modify the existing examples so that the org code that is
exported also creates the code-blocks that are executed.

Ref: https://list.orgmode.org/ZTEML8zWrB6kQflk@toolbox/T/
---
 org-contrib/babel/languages/ob-doc-ditaa.org | 48 +++++++++++++++-----
 1 file changed, 36 insertions(+), 12 deletions(-)

diff --git a/org-contrib/babel/languages/ob-doc-ditaa.org b/org-contrib/babel/languages/ob-doc-ditaa.org
index 0ae949c2..f2c31a49 100644
--- a/org-contrib/babel/languages/ob-doc-ditaa.org
+++ b/org-contrib/babel/languages/ob-doc-ditaa.org
@@ -57,18 +57,34 @@ Activate evaluation of =ditaa= source code blocks by adding =ditaa= to
      '((ditaa . t))) ; this line activates ditaa
 #+END_SRC
 
+** Customization Options
+Org needs to know a few things about =ditaa= and the =java= executable in order to function. The following is a list of variables that can be customized.
+
+- org-ditaa-jar-path :: The path to the =ditaa= jar file.
+- org-babel-ditaa-java-cmd :: The name or path to the Java executable used to run the =ditaa= jar file.
+- org-ditaa-eps-jar-path :: The path to the =ditaaeps= jar file. [[https://ditaa-addons.sourceforge.net/][DitaaEps]] is maintained as part of the [[https://ditaa-addons.sourceforge.net/][ditaa-addons]] project.
+- org-ditaa-jar-option :: The prefix used before the =ditaa= jar path. The default is =-jar=.
+
 * Babel Features for ditaa Code Blocks
 ** Header Arguments
-   - file :: =ditaa= source code blocks require that an output file be specified
-   - cmdline :: specify [[http://ditaa.sourceforge.net/#usage][command line arguments]] for =ditaa=
-   - java :: arguments for the =java= runtimes (JRE) 
+   - file :: the output filename (mandatory)
+   - cmdline :: [[http://ditaa.sourceforge.net/#usage][command line arguments]] for =ditaa=
+   - java :: arguments for the =java= runtimes (JRE)
+   - eps :: produce an =eps= output file using =ditaaeps=
+   - pdf :: produce a =pdf= output file using =ditaaeps= followed by =epstopdf=
+
 ** Sessions
    =ditaa= does not support sessions.
 ** Result Types
 =Ditaa= source code blocks return a link to a [[http://www.libpng.org/pub/png/][png]] bitmap file.
 * Examples of Use
+** Hello World
 The obligatory Hello World! example in =ditaa=:
-#+BEGIN_EXAMPLE
+
+#+NAME: hello-world.org
+#+BEGIN_SRC org :exports code :results replace
+,#+NAME: hello-world
+,#+HEADER: :exports results
 ,#+BEGIN_SRC ditaa :file images/hello-world.png
 +--------------+
 |              |
@@ -76,9 +92,11 @@ The obligatory Hello World! example in =ditaa=:
 |              |
 +--------------+
 ,#+END_SRC
-#+END_EXAMPLE
+#+END_SRC
 
-#+header: :exports results
+#+RESULTS: hello-world.org
+#+NAME: hello-world
+#+HEADER: :exports results
 #+BEGIN_SRC ditaa :file images/hello-world.png
 +--------------+
 |              |
@@ -87,23 +105,29 @@ The obligatory Hello World! example in =ditaa=:
 +--------------+
 #+END_SRC
 
-#+RESULTS:
+#+RESULTS: hello-world
 [[file:images/hello-world.png]]
+** Passing command-line options to =ditaa=
 
 Now, round all corners by passing =ditaa= the =-r,--round-corners=
 command line switch.
 
-#+BEGIN_EXAMPLE
-#+BEGIN_SRC ditaa :file images/hello-world-round.png :cmdline -r
+#+NAME: hello-world-round.org
+#+BEGIN_SRC org :exports code :results replace
+,#+NAME: hello-world-round
+,#+HEADER: :exports results
+,#+BEGIN_SRC ditaa :file images/hello-world-round.png :cmdline -r
 +--------------+
 |              |
 | Hello World! |
 |              |
 +--------------+
+,#+END_SRC
 #+END_SRC
-#+END_EXAMPLE
 
-#+header: :exports results
+#+RESULTS: hello-world-round.org
+#+NAME: hello-world-round
+#+HEADER: :exports results
 #+BEGIN_SRC ditaa :file images/hello-world-round.png :cmdline -r
 +--------------+
 |              |
@@ -112,6 +136,6 @@ command line switch.
 +--------------+
 #+END_SRC
 
-#+RESULTS:
+#+RESULTS: hello-world-round
 [[file:images/hello-world-round.png]]
 
-- 
2.42.0

Re: org-ditaa woes

[Ihor Radchenko]

Leo Butler <Leo.Butler@umanitoba.ca> writes:

>> Writing a patch is also welcome.
>
> Here is a patch to the documentation. It documents currently
> undocumented *features* of ob-ditaa.
>
> I have *removed* mention of work-arounds to execute scripts. I have also
> taken the liberty of re-writing the two source blocks to use org src
> blocks.

Thanks!
Applied, onto master.
https://git.sr.ht/~bzg/worg/commit/3e1c006b

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Jarmo Hurri]

Greetings all.

Ihor Radchenko <yantar92@posteo.net> writes:

> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>>>> In my current source I see [...]
>>>>
>>>> (use C-h v org-babel-ditaa-java-cmd to see the value of the java
>>>> executable — you can then customize this to use a different command)
>>>
>>> As far as I understand that part of code it still kind-of assumes that
>>> I'm using a command line of type "java -jar ditaa.jar ...", just with
>>> more flexibility in choosing which "java" command I'm using, right?
>>
>> Yes, it does. ob-plantuml already migrated to allow a regular command,
>> but ob-ditaa still only enables using the jar directly.
>>
>> That is something which would be nice to fix — and ob-plantuml should
>> show the path forward.
>
> +1
> This is a relatively simple task.
> One can indeed use ob-plantuml as a reference to extend ob-ditaa.

It looks like this has not been addressed yet, so I will try to tackle
the problem in the next couple of days.

All the best,

Jarmo