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.
"Berry, Charles" writes:
> Max,
>
>> On Dec 31, 2021, at 4:05 AM, Max Nikulin 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
Max Nikulin 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
Max,
> On Dec 31, 2021, at 4:05 AM, Max Nikulin 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.
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
Rudy,
> On Dec 29, 2021, at 11:26 PM, Rudolf Adamkovič 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
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
Rudolf Adamkovič via "General discussions about Org-mode."
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
"Berry, Charles" writes:
> Rudy,
>
> Thanks for the comment, but ...
>
>> On Dec 25, 2021, at 1:37 PM, Rudolf Adamkovič 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"
Max,
> On Dec 29, 2021, at 4:53 AM, Max Nikulin 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:
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
Max Nikulin 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
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 .
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
>
>
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
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).
Rudy
--
"'Contrariwise,' continued Tweedledee, 'if it was so, it
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')?
Thanks for reminding about `org-babel-load-languages'.
Note that `org-babel-execute-src-block' (called by
org-babel-execute-buffer)
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,
Rudy,
Thanks for the comment, but ...
> On Dec 25, 2021, at 1:37 PM, Rudolf Adamkovič 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
Ihor Radchenko 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
"Berry, Charles" 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.
> On Dec 23, 2021, at 8:09 PM, Ihor Radchenko wrote:
>
> Rudolf Adamkovič 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,
Rudolf Adamkovič 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
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
Rudolf Adamkovič 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
> On Dec 21, 2021, at 2:53 PM, Rudolf Adamkovič 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
Ihor Radchenko 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
> On Dec 18, 2021, at 11:57 AM, Charles Berry 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
> On Dec 18, 2021, at 1:49 AM, Ihor Radchenko wrote:
>
> "Berry, Charles" 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
"Berry, Charles" 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
> On Dec 16, 2021, at 8:51 PM, Kyle Meyer 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:
>>
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
32 matches
Mail list logo
