On Sat, Nov 11 2023, Ihor Radchenko <yanta...@posteo.net> wrote: > Leo Butler <leo.but...@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