emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] lisp/ob-plantuml.el: Insert results in buffer


From: Ihor Radchenko
Subject: Re: [PATCH] lisp/ob-plantuml.el: Insert results in buffer
Date: Tue, 02 Aug 2022 20:42:33 +0800

Joseph Turner <joseph@breatheoutbreathe.in> writes:

> I've added a couple of (message ...) blocks to log the value of
> do-export and params. It appears that this combination is producing a
> params value which is equivalent to the value of params produced by the
> current org-babel-execute:plantuml function. However, when the above
> function is executed on a block like:
>
> #+begin_src plantuml :file "this.png"
>   Bob->Alice : Hello1!
> #+end_src
>
> I get "Code block produced no output."
>
> I suspect that setting the scoped params variable has no effect on the
> execution of the function, since I can set params to '((:results .
> "none")), and I'll still get a printed result if
> org-babel-default-header-args:plantuml is set to the above value.

This is because you did not really modify the params value.
Inserting results happens outside the org-babel-execute:plantuml. You
can check out org-babel-execute-src-block function.

(params (if do-export
           (map-merge 'list params '((:results . "file") (:result-params 
"replace" "file")))
         params)

This snippet only binds the value locally, restoring it after exiting
the let-binding. You may need to modify the params destructively using
setf and assq.

> Is it safe to modify the value of org-babel-default-header-args:plantuml
> from within the function? Would that even work?

This is not only unsafe, but will also have no effect on the current
execution. The passed params argument is a result of parsing global
header args, default header args for specific language, file-local
header args, subtree-local header args, and src block-specific header
args combined.

Strictly speaking, it is normal for org-babel to require the user to
specify the output format explicitly via :results output or :results
file or any other available setting. Having a :file argument must be
accompanied by :results file.

However, the ob-plantuml default value makes this generic org-babel
requirement not necessary, which was a useful feature as long as only
the :file output was supported.

The most self-consistent way to introduce non-file output would be
changing the default header args for plantuml to nil - it would make
things consistent with all other generic backends.

Unfortunately, such change is not an option because it will break the
existing Org files for users accustomed to :file header arg implying
:results file in their existing src blocks.

Probably the most consistent way to approach the new output format would
be throwing an error if :file is not provided, but :results is set to
file. I'd say that it will be much more consistent with other babel
backends, albeit less "smart".

Best,
Ihor



reply via email to

[Prev in Thread] Current Thread [Next in Thread]