From: Max Nikulin <manikulin@gmail.com>
To: "52545@debbugs.gnu.org" <52545@debbugs.gnu.org>
Subject: bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
Date: Tue, 4 Jan 2022 21:59:48 +0700 [thread overview]
Message-ID: <af156694-2777-c0b6-0f39-d184a2e1b6f6@gmail.com> (raw)
In-Reply-To: <87mtknsdhm.fsf@localhost>
Since debbugs is not the primary bug tracker, it is better to close this
issue on debbugs and maybe confirm it for https://updates.orgmode.org/
From my point of view, making babel aware that some widely used
languages are data-only (so evaluation does not make sense) improves
user experience.
On the other hand there is no support of BibTeX in babel, so current
behavior is correct: attempt to execute a block of a language that is
not enabled causes an error. (While I was reading first messages in this
thread, it was not obvious for me that there in no ob-bibtex.el package.)
Anyway emacs requires enough customization, so
(setq org-babel-default-header-args:bibtex '((:eval . "no")))
globally in inti.el or per-file setting
#+property: header-args:bibtex :eval no
should not be a problem. User can achieve desired behavior with no
changes in org code.
On 26/12/2021 20:27, Ihor Radchenko wrote:
>
> Thanks for reminding about `org-babel-load-languages'.
> Note that `org-babel-execute-src-block' (called by
> org-babel-execute-buffer) does not really use it. It just checks for
> (intern (concat "org-babel-execute:" lang)).
>
> Maybe we just should not throw an error when lang is not in
> `org-babel-load-languages'? Or maybe we can check for this in
> `org-babel-confirm-evaluate'.
Berry, Charles. Fri, 17 Dec 2021 19:25:52 +0000
https://list.orgmode.org/A4FB4F42-64A8-4D6D-A621-D621E1AA1F04@health.ucsd.edu
> If I have a typo in the name of a language, the error message you
> quote tells me what my mistake was.
Certainly, if some language is mentioned in `org-babel-load-languages'
than it is not a typo, but as I wrote earlier, I do not think, nil
should work as ":eval no".
Side note: to notify users about a typo, it is better to check all
source blocks in advance before starting to execute them in
`org-babel-execute-buffer'. Export may issue warnings as well even when
evaluation is disabled. See P.S. below for one more note.
I do not mind using `org-babel-load-languages' more widely. However
massive clean up of worg is required to change abundant examples that
replace `org-babel-load-languages' by calling
`org-babel-do-load-languages'. The latter is intended for `defcustom'.
It is better to provide incremental functions to load and unload
languages for usage in init files or source blocks. Direct (require
'ob-something) becomes less favorable as well.
Some symbol like "noeval" may be added to nit and t as values of
`org-babel-load-languages' pairs.
Berry, Charles. Fri, 31 Dec 2021 19:11:45 +0000.
https://list.orgmode.org/F641D224-52FC-45D8-95F0-9E99F824E1F7@health.ucsd.edu
> #+name: yaml_header_1
> #+begin_export yaml
Rudy wrote that it prevents tangling. I can add that it prevents export
to e.g. HTML for documentation how to configure something that has two
representations: executable script and steps that can be followed by
manually typing commands and editing configuration files.
So I consider data-only languages as a convenient feature.
From security reasons I would like to have possibility to disable
evaluation in a such way that it is impossible to override through
per-file variables or properties.
Are we going to change anything related to `org-babel-load-language' and
`org-babel-execute-buffer' or maybe just add a set
`org-babel-default-header-args:something variables'?
P.S.
Berry, Charles. Sat, 18 Dec 2021 20:13:15 +0000.
https://list.orgmode.org/C61FBF93-064B-4FB2-9378-39D3078F108E@health.ucsd.edu
> Also, when exporting it looks `org-babel-exp-results' does not
> attempt to run src blocks for which
>
> (fboundp (intern (concat "org-babel-execute:" lang)))
>
> is nil.
>
> So doing an export should `just work'.
I would say that it is hardly consistent with mistake detection as a
feature.
next prev parent reply other threads:[~2022-01-04 15:22 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m2h7b8u9a7.fsf@me.com>
2021-12-17 4:51 ` bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks Kyle Meyer
2021-12-17 19:25 ` Berry, Charles
2021-12-18 9:49 ` Ihor Radchenko
2021-12-18 19:57 ` Berry, Charles
2021-12-18 20:13 ` Berry, Charles
2021-12-21 22:53 ` Rudolf Adamkovič via General discussions about Org-mode.
2021-12-21 23:14 ` Berry, Charles
2021-12-22 15:04 ` Ihor Radchenko
2021-12-23 22:00 ` Rudolf Adamkovič via General discussions about Org-mode.
2021-12-24 4:09 ` Ihor Radchenko
2021-12-24 19:52 ` Berry, Charles
2021-12-25 21:37 ` Rudolf Adamkovič via General discussions about Org-mode.
2021-12-25 23:34 ` Berry, Charles
2021-12-30 7:26 ` Rudolf Adamkovič via General discussions about Org-mode.
2021-12-30 8:00 ` Rudolf Adamkovič via General discussions about Org-mode.
2021-12-31 12:05 ` Max Nikulin
2021-12-31 19:11 ` Berry, Charles
2022-01-01 20:32 ` Rudolf Adamkovič via General discussions about Org-mode.
2022-01-01 20:23 ` Rudolf Adamkovič via General discussions about Org-mode.
2021-12-30 20:14 ` Berry, Charles
2021-12-29 12:53 ` Max Nikulin
2021-12-29 17:47 ` Berry, Charles
2021-12-30 15:41 ` Max Nikulin
2021-12-25 21:40 ` Rudolf Adamkovič via General discussions about Org-mode.
2021-12-26 12:49 ` Max Nikulin
2021-12-26 13:27 ` Ihor Radchenko
2022-01-04 14:59 ` Max Nikulin [this message]
2021-12-26 19:51 ` Rudolf Adamkovič
2021-12-27 11:18 ` Max Nikulin
2021-12-27 21:37 ` Rudolf Adamkovič via General discussions about Org-mode.
2021-12-28 11:45 ` Max Nikulin
2021-12-28 20:39 ` Rudolf Adamkovič via General discussions about Org-mode.
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=af156694-2777-c0b6-0f39-d184a2e1b6f6@gmail.com \
--to=manikulin@gmail.com \
--cc=52545@debbugs.gnu.org \
/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).