Leo Butler <leo.but...@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>
