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>