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