From: Ihor Radchenko <yantar92@gmail.com>
To: Joseph Turner <joseph@breatheoutbreathe.in>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] lisp/ob-plantuml.el: Insert results in buffer
Date: Tue, 02 Aug 2022 20:42:33 +0800 [thread overview]
Message-ID: <874jyulsue.fsf@localhost> (raw)
In-Reply-To: <875yjdkk25.fsf@breatheoutbreathe.in>
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
prev parent reply other threads:[~2022-08-02 12:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 23:15 [PATCH] lisp/ob-plantuml.el: Insert results in buffer Joseph Turner
2022-07-25 13:15 ` Ihor Radchenko
2022-07-25 19:52 ` Joseph Turner
2022-07-26 5:50 ` Ihor Radchenko
2022-07-27 20:51 ` Joseph Turner
2022-07-28 14:36 ` Ihor Radchenko
2022-07-31 22:05 ` Joseph Turner
2022-08-02 12:42 ` Ihor Radchenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jyulsue.fsf@localhost \
--to=yantar92@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=joseph@breatheoutbreathe.in \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).