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 +. https//list.orgmode.org87wn4ks2j5@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
  <>
  ,#+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: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Leo Butler]

On Sat, Nov 11 2023, Ihor Radchenko  wrote:

> Leo Butler  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

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

[Ihor Radchenko]

Leo Butler  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 .
Support Org development at ,
or support my work at 

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

[Ihor Radchenko]

Leo Butler  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 .
Support Org development at ,
or support my work at 

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

[Leo Butler]

On Fri, Nov 10 2023, Max Nikulin  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

[Leo Butler]

On Fri, Nov 10 2023, Ihor Radchenko  wrote:

> Leo Butler  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

[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

[Ihor Radchenko]

Leo Butler  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 .
Support Org development at ,
or support my work at 

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

[Ihor Radchenko]

Leo Butler  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 .
Support Org development at ,
or support my work at 

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

[Leo Butler]

On Thu, Nov 09 2023, Max Nikulin  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

[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 Sat, Oct 21 2023, Ihor Radchenko  wrote:

> "Dr. Arne Babenhauserheide"  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

From 6424527dde6e487ce55dddae1260df3d84c2775e Mon Sep 17 00:00:00 2001
From: Leo Butler 
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 ..8a039e1bad997ebd31d8906cc1d1f234e9159e09
GIT binary patch
literal 3314
zcmchacQjn<8pcV8kQk!(8ex#lXzy7#|(_gZ`J_5HEm_xslOd!FyviDo7S%uIYtG
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^*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|>8lctE-k(GvAtBe%mmNWybG`8_ySuwE7;G<0
zMJIWt0N#YW*qp+E-dsFcPVX+Ii>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`$m$@clLSJTxsWZEbCBe}6y8m;8M^skKT^zF~Yy3z`JPX``$xcb74vi7PdiPF+uSqUvT2k@;8AbFL*uk5Xh`jEo=
zq?ntF%f;1o*>_{MA#J%>-p9x1SUuqT*zBy0xp+ujb@j${6*u4hpG0{Dg?a!oCY>_Tk~-
z=z`bQ^QMeG2t4advX1N
zHtsvern%Bnis!9?ljGyDOt)o`wDaJ80%N9(Wj(0`eE~gTy=(5MrA3n?V
zWpE?jk>_w`2gkdkdL8=r??%shb3TAESL=;xhX3b`oK(`Ej!gb3alBUW&u~*D}9OVN9-T8Wj}1qw@HGwKEEri
z2*0~DZ(SoKZg@B(-<4p>9Er!{@0`Tw;h6_|;tBzsU{kxg!U4}D*4zQ#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)Xh;YPEKat8+3bsq4XcKY|%EzIgMlWC?lSMKg_0PVTo_1
z*I9^R$#Evo2$$#A?o5DEBOP!}XF_$E{6RnK^*b=#ORna32`ej)EVUh{(uFlUYtb~~
zV#R)BO^I?ZTFs=C~iAz?)u{mD9pMgu{;`FD{1e7uINi6^**ZOx1t8P@d5U)GC1T
zva?4M0A^60t5Rmv*BZ0La7wa^esu#mu~*h0XRwe){(h>Fm%KR
zn^-7em>o3zC$X-1-ZZX<13t%xcNln$W@KcnAd|_LnVC1IUb9<|5xcEo?3=Mbh5^
z)MNWz)R@{=D=ZsO@6qFL?^#gwG(Hg5*QhTWF!$Cg|M~OiBLH4fy=jrg@`u#6u#+Re
z*nQMUqg6;or+%zowuD9uNad{0w*@bDg`Y*yUkZRKc+n=jyXK>I^@zG3>lS_X=!WQU!T6jg2XT__xAQa
zF6B8FZRoBbA`#~hTH{`fz5x#wxXFoz>q|-CuKN8`>F6v&2He$&|2`CbjRwxs>7bHC
zR7G`l01}yL4waXe-yXW&=gGmr0d&?O#Kh1U=H}*tlhKipk)%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}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`<{MnCUQmaWBhpqh9a{_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~^`IMr9HPEXto0mywpPww8%Qw)-gbc5ily>C@%vg=PNA%mxejE{_6X
qFe5|u|7~zz&&*;q`m06S8LeG+hGOd>J{tI!p)t}k(XG{f81;7r

literal 0
HcmV?d1

diff --git a/org-contrib/babel/languages/ob-doc-ditaa.org 

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

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  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 .
Support Org development at ,
or support my work at