emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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")))

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".


      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:

  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 \


* 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


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).