bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Kyle Meyer]

Rudolf Adamkovič:

> I have a .org file with two kinds of src blocks:
>
> 1. sqlite blocks
> 2. bibtex blocks
>
> I want to execute all sqlite blocks with org-babel-execute-buffer.
>
> When I try to do so, org-mode complains:
>
> org-babel-execute-src-block: No org-babel-execute function for bibtex!
>
> I know I can work around the problem (as one does in org-mode) with:
>
> #+property: header-args:bibtex+ :eval no
>
> Then, why not skip the irrelevant blocks, the ones with no execute functions, by default?

I don't know, but I've reassigned this bug in order to redirect this to
the Org list, which serves as the primary place for Org development and
discussion.

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 16, 2021, at 8:51 PM, Kyle Meyer <kyle@kyleam.com> wrote:
> 
> Rudolf Adamkovič:
> 
>> I have a .org file with two kinds of src blocks:
>> 
>> 1. sqlite blocks
>> 2. bibtex blocks
>> 
>> I want to execute all sqlite blocks with org-babel-execute-buffer.
>> 
>> When I try to do so, org-mode complains:
>> 
>> org-babel-execute-src-block: No org-babel-execute function for bibtex!
>> 
>> I know I can work around the problem (as one does in org-mode) with:
>> 
>> #+property: header-args:bibtex+ :eval no
>> 
>> Then, why not skip the irrelevant blocks, the ones with no execute functions, by default?


If I have a typo in the name of a language, the error message you quote tells me what my mistake was. 

I'd say that is a feature, not a bug.

HTH,
Chuck

> 
> I don't know, but I've reassigned this bug in order to redirect this to
> the Org list, which serves as the primary place for Org development and
> discussion.
> 

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Ihor Radchenko]

"Berry, Charles" <ccberry@health.ucsd.edu> writes:

> If I have a typo in the name of a language, the error message you quote tells me what my mistake was. 
>
> I'd say that is a feature, not a bug.

Agree. However, some languages simply do not define babel execute
function. The error is same regardless whether a language backend is not
available/not loaded or the backend is loaded, but does not provide
babel execute function.

Maybe we can provide a custom list of languages where we do not throw
the error? If a language is in the list and there is no babel execute
function, we can simply ignore the source block. If a language is in the
list, but there is babel execute function, we throw another error.

Though I am not a big fan of introducing yet another customisation.
Maybe someone has better ideas?

Best,
Ihor

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 18, 2021, at 1:49 AM, Ihor Radchenko <yantar92@gmail.com> wrote:
> 
> "Berry, Charles" <ccberry@health.ucsd.edu> writes:
> 
>> If I have a typo in the name of a language, the error message you quote tells me what my mistake was. 
>> 
>> I'd say that is a feature, not a bug.
> 
> Agree. However, some languages simply do not define babel execute
> function. The error is same regardless whether a language backend is not
> available/not loaded or the backend is loaded, but does not provide
> babel execute function.
> 
> Maybe we can provide a custom list of languages where we do not throw
> the error? If a language is in the list and there is no babel execute
> function, we can simply ignore the source block. If a language is in the
> list, but there is babel execute function, we throw another error.
> 
> Though I am not a big fan of introducing yet another customisation.
> Maybe someone has better ideas?
> 

I believe there is a feeling that org-babel is already so complicated that adding features should be avoided. 

There are workable approaches under the current setup. 

---

For one, you can define lang specific header-args, so just define :eval no for the lang's that you want to use, but that do not have org-babel-execute:<lang> defined: 

#+property: header-args:nada :eval no
#+property: header-args :exports both :eval yes

The code here will be rendered, but the block will not execute:

#+begin_src nada
  "haha"
#+end_src

---

Another is to use a custom :eval arg like this:

#+property: header-args :eval (my-eval-p) :exports both

#+begin_src not_defined
  "haha"
#+end_src

Where `my-eval-p' is defined as:

#+begin_src emacs-lisp
  (defun my-eval-p ()
    (let ((lang (car (org-babel-get-src-block-info 'light))))
      (if (fboundp (intern (concat "org-babel-execute:" lang)))
	  "yes"
	"no")))
#+end_src

Obviously, you can elaborate `my-eval-p' to satisfy individual needs.

Best,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 18, 2021, at 11:57 AM, Charles Berry <ccberry@health.ucsd.edu> wrote:
> 
> There are workable approaches under the current setup. 
> 
> -


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

HTH,

Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

Ihor Radchenko <yantar92@gmail.com> writes:

> Though I am not a big fan of introducing yet another customisation.
> Maybe someone has better ideas?

I struggle to understand.  Why do we need a customization?  If Org knows
that some backend exists but has no execute function, why does it even
try to execute it?  It cannot.  Do I miss something?

Rudy
-- 
"Logic is a science of the necessary laws of thought, without which no employment of the understanding and the reason takes place." -- Immanuel Kant, 1785

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 21, 2021, at 2:53 PM, Rudolf Adamkovič <salutis@me.com> wrote:
> 
> I struggle to understand.  Why do we need a customization?  If Org knows
> that some backend exists but has no execute function, why does it even
> try to execute it?  It cannot.  Do I miss something?


Sorry if my prior posts were garbled. To clarify:

When exporting src blocks for which there is no execute function for the lang, the block will not be executed and the export will proceed.

When evaluating src blocks in other circumstances, e.g. M-x org-babel-execute-buffer, the process will terminate when org-babel-execute-src-block issues `(error "No org-babel-execute function for %s!" lang))'

The latter can be a clue that the name of a lang is misspelled or that org-babel-load-languages needs to be customized to provide the execute function.

IMO, nothing needs fixing. The ability to handle OP's original issue is already in place.

HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Ihor Radchenko]

Rudolf Adamkovič <salutis@me.com> writes:

>> Though I am not a big fan of introducing yet another customisation.
>> Maybe someone has better ideas?
>
> I struggle to understand.  Why do we need a customization?  If Org knows
> that some backend exists but has no execute function, why does it even
> try to execute it?  It cannot.  Do I miss something?

There no notion of backend in Org babel. Babel backends are merely
defining a set of functions with special function symbols
(org-babel-*:lang_name). So, Org cannot distinguish between language
backends that are simply not loaded and the ones that do not define
org-babel-execute:lang.

Best,
Ihor

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

Ihor Radchenko <yantar92@gmail.com> writes:

> So, Org cannot distinguish between language backends that are simply
> not loaded and the ones that do not define org-babel-execute:lang.

Oh, if we have this architectural limitation in place, then Org cannot
help the user, and every user will have "explain" to Org that executing
BibTeX makes no sense.  I guess we can then close this bug then!

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Ihor Radchenko]

Rudolf Adamkovič <salutis@me.com> writes:

>> So, Org cannot distinguish between language backends that are simply
>> not loaded and the ones that do not define org-babel-execute:lang.
>
> Oh, if we have this architectural limitation in place, then Org cannot
> help the user, and every user will have "explain" to Org that executing
> BibTeX makes no sense.  I guess we can then close this bug then!

Not necessarily close. As I proposed above, one way is adding a user
customisation. And we do not have to force the users adding trivial
things like bibtex. Bibtex may be one of the defaults.

Best,
Ihor

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 23, 2021, at 8:09 PM, Ihor Radchenko <yantar92@gmail.com> wrote:
> 
> Rudolf Adamkovič <salutis@me.com> writes:
> 
>>> So, Org cannot distinguish between language backends that are simply
>>> not loaded and the ones that do not define org-babel-execute:lang.
>> 
>> Oh, if we have this architectural limitation in place, then Org cannot
>> help the user, and every user will have "explain" to Org that executing
>> BibTeX makes no sense.  I guess we can then close this bug then!
> 
> Not necessarily close. As I proposed above, one way is adding a user
> customisation. And we do not have to force the users adding trivial
> things like bibtex. Bibtex may be one of the defaults.

Honestly, I think there is no problem here to solve. 

If there is a use case that you think I didn't cover below, please provide an ECM and directions for triggering the unwanted behavior.

Details:

---

Exports do not eval blocks for which there is no org-babel-execute:<lang>.

So, `C-c C-e l L' (and so on) will *not eval* bibtex src blocks.

The problem cited here *only* exists for execution using org-babel-execute-buffer or similar functions.

For that case, setting buffer or heading properties, such as:

#+begin_src org
  :PROPERTIES:
  :header-args: :eval yes :exports results
  :header-args:bibtex: :eval no
  :END:
#+end_src

resolves the issue.

So the user needs to add just one-line per language to set this up.

Following (info "(org) Property Syntax") the user can set this behavior for all Org files by customize-ing `org-global-properties', whose docstring gives plentiful details.

---



HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

"Berry, Charles" <ccberry@health.ucsd.edu> writes:

> The problem cited here *only* exists for execution using
> org-babel-execute-buffer or similar functions.
>
> For that case, setting buffer or heading properties, such as […]
> resolves the issue.
>
> So the user needs to add just one-line per language to set this up.

I think we look at the problem from two different perspectives.  You
look at the problem from the "how" perspective, whereas I look at it
from the "why" perspective.  Sure, we can work around everything in Org.
Now, does that mean that Org should try to execute BibTeX blocks when
executing a buffer?  I do not think so.

Rudy

-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

Ihor Radchenko <yantar92@gmail.com> writes:

> And we do not have to force the users adding trivial things like
> bibtex. Bibtex may be one of the defaults.

I see. In effect, Org would not try to "execute BibTeX" when executing a
buffer. That makes sense!

Rudy
-- 
"I love deadlines. I love the whooshing noise they make as they go by."
-- Douglas Adams, The Salmon of Doubt

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

Rudy,

Thanks for the comment, but ...

> On Dec 25, 2021, at 1:37 PM, Rudolf Adamkovič <salutis@me.com> wrote:
> 
> I think we look at the problem from two different perspectives.  You
> look at the problem from the "how" perspective, whereas I look at it
> from the "why" perspective.  Sure, we can work around everything in Org.
> Now, does that mean that Org should try to execute BibTeX blocks when
> executing a buffer?  I do not think so.

Using standard features (properties, header-args) in a standard way does not strike me as a `work around'.

You have not made a clear case that src blocks are even needed to support your use case. It may well be that export blocks (which never execute) would work just as well.  But with no ECM, one can only guess.

I'm still inclined to call this a feature request, not a bug. And decisions about adding complexity to an already complicated code base should take that point of view, IMO.

Best,

Chuck

Re: bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Max Nikulin]

On 24/12/2021 05:00, Rudolf Adamkovič wrote:
> Ihor Radchenko writes:
> 
>> So, Org cannot distinguish between language backends that are simply
>> not loaded and the ones that do not define org-babel-execute:lang.
> 
> Oh, if we have this architectural limitation in place, then Org cannot
> help the user, and every user will have "explain" to Org that executing
> BibTeX makes no sense.  I guess we can then close this bug then!

Rudolf, do have support BibTeX as babel language loaded to Org (by 
customization of `org-babel-load-languages' or by explicit `require')?

Re: bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> Rudolf, do have support BibTeX as babel language loaded to Org (by 
> customization of `org-babel-load-languages' or by explicit `require')?

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

Best,
Ihor

Re: bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič]

Max Nikulin <manikulin@gmail.com> writes:

> Rudolf, do have support BibTeX as babel language loaded to Org (by
> customization of `org-babel-load-languages' or by explicit `require')?

I have it listed in org-babel-do-load-languages as (bibtex . nil).

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Max Nikulin]

I am sorry that I sent previous message to emacs-orgmode list only, not 
to debbugs.

On 27/12/2021 02:51, Rudolf Adamkovič wrote:
> Max Nikulin writes:
> 
>> Rudolf, do have support BibTeX as babel language loaded to Org (by
>> customization of `org-babel-load-languages' or by explicit `require')?
> 
> I have it listed in org-babel-do-load-languages as (bibtex . nil).

Let's consider the following example:

---- >8 ----
Test

#+begin_src elisp
   (message "Test")
#+end_src
---- 8< -----

emacs -Q -L ~/src/org-mode/lisp/ --eval "(custom-set-variables 
'(org-babel-load-languages '((emacs-lisp . nil))))" babel-exec.org

Do you agree that "No org-babel-execute function for elisp!" is a 
reasonable reaction to `org-babel-execute-buffer`?

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

Max Nikulin <manikulin@gmail.com> writes:

> Let's consider the following example:
>
> ---- >8 ----
> Test
>
> #+begin_src elisp
>    (message "Test")
> #+end_src
> ---- 8< -----
>
> emacs -Q -L ~/src/org-mode/lisp/ --eval "(custom-set-variables 
> '(org-babel-load-languages '((emacs-lisp . nil))))" babel-exec.org
>
> Do you agree that "No org-babel-execute function for elisp!" is a 
> reasonable reaction to `org-babel-execute-buffer`?

The user did ask Org to load "emacs-lisp" but to never execute it.
Thus, I would expect Org to do just that.  What do you think?

-- 
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place." -- Immanuel
Kant, 1785

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Max Nikulin]

On 28/12/2021 04:37, Rudolf Adamkovič wrote:
> Max Nikulin writes:
> 
>> Let's consider the following example:
>>
>> ---- >8 ----
>> Test
>>
>> #+begin_src elisp
>>     (message "Test")
>> #+end_src
>> ---- 8< -----
>>
>> emacs -Q -L ~/src/org-mode/lisp/ --eval "(custom-set-variables
>> '(org-babel-load-languages '((emacs-lisp . nil))))" babel-exec.org
>>
>> Do you agree that "No org-babel-execute function for elisp!" is a
>> reasonable reaction to `org-babel-execute-buffer`?
> 
> The user did ask Org to load "emacs-lisp" but to never execute it.
> Thus, I would expect Org to do just that.  What do you think?

No, it means instruction to unload support of emacs-lisp even it was 
loaded before.

See info "(org) Languages" https://orgmode.org/manual/Languages.html and 
`org-babel-do-load-languages' function. The latter may be considered too 
technical for ordinary user, but examples of its usage are excessively 
proliferated, e.g. it is mentioned for every supported language on Worg 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-octave.html

The function is called when the value of `org-babel-load-languages' is 
changed through easy customization interface, so (emacs-lisp . nil) is a 
command rather than a declaration.

The use case is to temporary enable support of some language and later 
to disable it again without terminating of emacs session. Just to avoid 
accidental execution of some snippet.

I can not say that your expectation of the effect of nil is a nonsense, 
but changing its interpretation may cause silent failures and as a 
result upset users. Consider that a file that includes source code 
blocks for different languages is moved to another machine (or 
configuration changed since previous execution on the same machine). It 
is better to get explicit error than to copy result in a hurry and to 
discover that it is incomplete some time later. Per-file and per-block 
configuration is safer against such pitfalls.

I do not insist that current behavior is the best possible. There are 
still some reasons behind such choice.

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

Max Nikulin <manikulin@gmail.com> writes:

> No, it means instruction to unload support of emacs-lisp even it was 
> loaded before.

I see.  Thank you for the explanation!  I misunderstood the (rather
unusual) "org-babel-do-load-languages" API despite having read the
documentation.

> I do not insist that current behavior is the best possible. There are 
> still some reasons behind such choice.

Then, perhaps Ihor had the best idea, where Org would become smart
enough to avoid "executing BibTeX" and similar?

Rudy
-- 
"I love deadlines. I love the whooshing noise they make as they go by."
-- Douglas Adams, The Salmon of Doubt

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Max Nikulin]

On 25/12/2021 02:52, Berry, Charles wrote:
> 
> For that case, setting buffer or heading properties, such as:
> 
> #+begin_src org
>    :PROPERTIES:
>    :header-args: :eval yes :exports results
>    :header-args:bibtex: :eval no
>    :END:
> #+end_src
> 
> resolves the issue.

Chuck, is it expected that the following form to specify properties 
suppresses of evaluation during export but allows execution during 
processing of `org-babel-execute-buffer'? I am puzzled that behavior for 
property drawer is different.

---- >8 ----
#+property: header-args :eval yes :exports both
#+property: header-args:elisp :eval no

#+begin_src elisp
   (message "From elisp")
#+end_src
---- 8< ----

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

Max,

> On Dec 29, 2021, at 4:53 AM, Max Nikulin <manikulin@gmail.com> wrote:
> 
> On 25/12/2021 02:52, Berry, Charles wrote:
>> For that case, setting buffer or heading properties, such as:
>> #+begin_src org
>>   :PROPERTIES:
>>   :header-args: :eval yes :exports results
>>   :header-args:bibtex: :eval no
>>   :END:
>> #+end_src
>> resolves the issue.
> 
> Chuck, is it expected that the following form to specify properties suppresses of evaluation during export but allows execution during processing of `org-babel-execute-buffer'? I am puzzled that behavior for property drawer is different.
> 

It isn't different when you have `:header-args:elisp: :eval no' in the drawer.

I get the message `Evaluation of this elisp code block is disabled.' either way.

Caveat: I am running release_9.5.1-233-ged5335.

But a couple of things:

1) Be sure to refresh when introducing `#+property' lines. If you paste in a property line and then org-babel-execute-src-block, the property will not be acknowledged. AFAICS, property drawers do not suffer from this. 

2) Property drawers only affect the heading under which they are placed unless placed at the top of the file. And either way, it is an error to insert a blank line above a property drawer. org-lint will complain although the message may be cryptic.

3) You probably know this, but exports use `org-babel-exp-process-buffer' which may perform differently than `org-babel-execute-buffer'. 




> ---- >8 ----
> #+property: header-args :eval yes :exports both
> #+property: header-args:elisp :eval no
> 
> #+begin_src elisp
>  (message "From elisp")
> #+end_src
> ---- 8< ----


HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

"Berry, Charles" <ccberry@health.ucsd.edu> writes:

> Rudy,
>
> Thanks for the comment, but ...
>
>> On Dec 25, 2021, at 1:37 PM, Rudolf Adamkovič <salutis@me.com> wrote:
>> 
>> I think we look at the problem from two different perspectives.  You
>> look at the problem from the "how" perspective, whereas I look at it
>> from the "why" perspective.  Sure, we can work around everything in
>> Org.  Now, does that mean that Org should try to execute BibTeX
>> blocks when executing a buffer?  I do not think so.
>
> Using standard features (properties, header-args) in a standard way
> does not strike me as a `work around'.

I apologize for the lack of clarity.  I used the term "workaround" from
the perspective of a user, who probably does not expect Org to try
"execute BibTeX" ever.

> You have not made a clear case that src blocks are even needed to
> support your use case. It may well be that export blocks (which never
> execute) would work just as well.  But with no ECM, one can only
> guess.

True that, I did not include an example!  Below, I include a typical use
case: Org notes about an article with a corresponding BibTeX entry.

(Note: I do not know what ECM stands for.)

[…]

#+property: header-args+ :comments link
#+cite_export: csl apa.csl

* Notes

[…]

* References

#+print_bibliography:

* Sources

#+begin_src bibtex :tangle knuth+2021.bib
@Article{knuth+2021,
  author       = {Knuth, Donald E. and Shustek, Len},
  title        = {Let's Not Dumb down the History of Computer Science},
  journal      = {Communications of the {ACM}},
  year         = 2021,
  volume       = 64,
  number       = 2,
  pages        = {33–35},
  month        = {jan},
  issue_date   = {February 2021},
  publisher    = {Association for Computing Machinery, {ACM}},
  issn         = {0001-0782},
  doi          = {10.1145/3442377},
  abstract     = {Donald Knuth on the best way to recognize the history
                  of computer science.},
  numpages     = 3
}
#+end_src

> I'm still inclined to call this a feature request, not a bug. And
> decisions about adding complexity to an already complicated code base
> should take that point of view, IMO.

Sure.  As a user, I can see it as both a bug, where Org tries to execute
BibTeX, but also as a feature, where Org needs to become smarter and
differentiate BibTeX from, say, Scheme or C.

Rudy
-- 
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place." -- Immanuel
Kant, 1785

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

Rudolf Adamkovič via "General discussions about Org-mode."
<emacs-orgmode@gnu.org> writes:

> Below, I include a typical use case: Org notes about an article with a
> corresponding BibTeX entry.

Please, ignore the example I gave, as it does not show anything.  I
apologize it.  Below, I provide a good example, one that made me stumble
upon the problem.

I have a paper that includes BibTeX blocks for references and SQLite
blocks to compute results.  I expect Org to execute all SQLite without
aborting to inform me that it could not execute BibTeX. Further, I
expect Org to it without me instructing it, for executing BibTeX does
not make sense.

#+title: …
#+author: Rudolf Adamkovič
#+email: salutis@me.com
#+property: header-args+ :comments link
#+cite_export: csl apa.csl
#+property: header-args:bibtex+ :exports none
#+property: header-args:bibtex+ :eval yes
#+options: toc:nil
#+latex_header: \usepackage{setspace}
#+latex_header: \doublespacing

* Abstract […]

* Introduction

[…] [cite/text:@beall-2019] explains […]

#+begin_src bibtex :tangle ~/bib/beall-2019.bib
[…]
#+end_src

[… 10 more BibTeX blocks used for the literature review]

* Methods […]

* Results

[…]

#+begin_src sqlite :db ~/tmp/test.db :exports none
[…]
#+end_src

[… 10 more SQLite blocks used to compute the results …]

[…]

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Max Nikulin]

On 30/12/2021 00:47, Berry, Charles wrote:
> 
> 1) Be sure to refresh when introducing `#+property' lines. If you
> paste in a property line and then org-babel-execute-src-block, the
> property will not be acknowledged. AFAICS, property drawers do not
> suffer from this.

Thank you, after C-c on the property line it works as expected. I was 
confused that export worked as expected and forgot that execute buffer 
may require activating just added lines.

I was lucky enough to avoid a pitfall with a blank line above property 
drawer. Usually I add empty line at the beginning of a file unless a 
shebang is required.

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

Rudy,

> On Dec 29, 2021, at 11:26 PM, Rudolf Adamkovič <salutis@me.com> wrote:
> 
> (Note: I do not know what ECM stands for.)


ECM stands for =Exemple Complet Minimal=, per https://orgmode.org/worg/org-faq.html#ecm, which says "The term refers to test files that can reliably reproduce a bug with the minimal amount of code."

It also references https://list.orgmode.org/orgmode/80oc3s13rg.fsf@somewhere.org/ for more details.

Roughly, an ECM is something a reader should be able to copy into a file and run "as is" on his/her setup. 

HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Max Nikulin]

On 30/12/2021 15:00, Rudolf Adamkovič wrote:
> 
> #+property: header-args:bibtex+ :eval yes

Why do you set ":eval yes" explicitly for bibtex if you believe that it 
should not be executed?

I suppose, the following may be considered as a complete example 
suitable to compare behavior of `org-babel-execute-buffer' and export:

---- >8 ----
#+property: header-args:bibtex+ :exports none

Test file with =bibtex= (to tangle)
and =elisp= (to execute) code blocks.

#+begin_src bibtex :tangle yes
   @misc{ex1,
     title = "Example"
   }
#+end_src

#+begin_src elisp
   (message "From elisp")
#+end_src
---- 8< ----

To solve the problem avoiding per-file configuration you can try

    (setq org-babel-default-header-args:bibtex '((:eval . "no")))

Unsure if it should be default. Since LaTeX export is important part of 
Org it is reasonable to expect that Org have some notion of BibTeX 
allowing to avoid execution of such source blocks.

Currently there is no BibTeX babel backend, but some user might create 
one that e.g. formats entries as some alternative to org-cite. Can 
default header arguments cause a problem in such case?

Should some function a macro be provided to facilitate declaring 
languages as data format (config files, JSON, YAML, etc.) rather than 
executable source code?

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

Max,

> On Dec 31, 2021, at 4:05 AM, Max Nikulin <manikulin@gmail.com> wrote:
> 
> 
> Should some function a macro be provided to facilitate declaring languages as data format (config files, JSON, YAML, etc.) rather than executable source code?

I think we already have this in the form of export blocks, viz.

#+name: yaml_header_1
#+begin_export yaml
output:
  html_document:
    toc: true
    toc_depth: 2
#+end_export

will be ignored by babel and by exporters that do not define a transcoder for `yaml' blocks.

The data can be used in transcoders for derived backends or in src blocks like this one:

#+begin_src emacs-lisp :var yaml_dat_1=yaml_header_1
  yaml_dat_1
#+end_src

And =C-c '= will invoke an edit buffer in yaml mode (if available).

And it seems that fontifying natively works just as with src blocks.

Best,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

Max Nikulin <manikulin@gmail.com> writes:

> On 30/12/2021 15:00, Rudolf Adamkovič wrote:
>> 
>> #+property: header-args:bibtex+ :eval yes
>
> Why do you set ":eval yes" explicitly for bibtex if you believe that
> it should not be executed?

Plain old stupidity.  :)

Rudy
-- 
"Programming reliably --- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible." --
Edsger W. Dijkstra (1981)

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Rudolf Adamkovič via General discussions about Org-mode.]

"Berry, Charles" <ccberry@health.ucsd.edu> writes:

> Max,
>
>> On Dec 31, 2021, at 4:05 AM, Max Nikulin <manikulin@gmail.com> wrote:
>> 
>> 
>> Should some function a macro be provided to facilitate declaring
>> languages as data format (config files, JSON, YAML, etc.) rather than
>> executable source code?
>
> I think we already have this in the form of export blocks, viz.

While "export" blocks do support "org-edit-special" and more, they do
not support ":tangle", right?  For BibTeX, one needs to tangle.

Rudy
-- 
"I love deadlines. I love the whooshing noise they make as they go by."
-- Douglas Adams, The Salmon of Doubt

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Max Nikulin]

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.