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

[Ihor Radchenko <yantar92@posteo.net>]

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>