[BUG] Inconsistent org-babel tangle behaviour

[BUG] Inconsistent org-babel tangle behaviour

[Thibaut Meyer via General discussions about Org-mode.]

Hi everyone,

setting a property in an org file like

'#+PROPERTY: header-args    :tangle "file.ext"'

with a source block of the form:
(note no language is specified for the block)

#+begin_src
<1: this block won't get tangled>
#+end_src

won't tangle the block

Adding any string as a language to the code block, like

#+begin_src random_string
<2: this block will get tangled>
#+end_src

tangles the code block

what's weirder is, just adding to a block the ":tangle" header without
or with any value, even with the value no, makes the tangling process
respect the header-args property value and thus the block will tangle
successfully.
(note no language is specified for the block)

#+begin_src :tangle no
<3: this block will get tangled!!>
#+end_src

Adding again a language value make the tangle header act normally

#+begin_src C :tangle no
<4: this block won't get tangled>
#+end_src

The behaviour doesn't seem super consistent. Ideally, I think having a
source block like the first one gettin tangled would be good, and having
the third one not tangle would be better as well.

The documentation states:
[Working with source code > Structure of Code Blocks]
"When ‘<language>’ identifier is omitted, the block also cannot have
‘<switches>’ and ‘<header arguments>’."

but, to my knowledge, there is no mention regarding the fact that the
headers assigned through the "header-args" property should not be
applied if a block has no language identifier.

I tested using org-mode pulled from the repo
"GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2)"
"Org mode version 9.8-pre (release_9.7.16-174-gb9637e @ /home/thibaut/tmp/org-mode/lisp/)"

Cheers

Re: [BUG] Inconsistent org-babel tangle behaviour

[Ihor Radchenko]

Thibaut Meyer via "General discussions about Org-mode."
<emacs-orgmode@gnu.org> writes:

> setting a property in an org file like
>
> '#+PROPERTY: header-args    :tangle "file.ext"'
>
> with a source block of the form:
> (note no language is specified for the block)
>
> #+begin_src
> <1: this block won't get tangled>
> #+end_src
>
> won't tangle the block

Currently, source blocks without language are never tangled.

> what's weirder is, just adding to a block the ":tangle" header without
> or with any value, even with the value no, makes the tangling process
> respect the header-args property value and thus the block will tangle
> successfully.
> (note no language is specified for the block)

> #+begin_src :tangle no
> <3: this block will get tangled!!>
> #+end_src

Here, a language is actually specified. The language is ":tangle" (there
is nothing stopping anyone from creating a language name starting from
colon).

> The behaviour doesn't seem super consistent. Ideally, I think having a
> source block like the first one gettin tangled would be good, and having
> the third one not tangle would be better as well.

Src block without language could indeed be tangled in your case.
However, if the :tangle value is set to something like "yes", there is
no way or can deduce the tangle file name.

Note that M-x org-lint warns about src blocks without language. While
src blocks without language are allowed syntactically, many Org features
will not work with such blocks.

Usually, you can simply use "conf" or "text" language name as a
placeholder.

I guess we can support the scenario you described, but I am not sure if
we should.

> The documentation states:
> [Working with source code > Structure of Code Blocks]
> "When ‘<language>’ identifier is omitted, the block also cannot have
> ‘<switches>’ and ‘<header arguments>’."
>
> but, to my knowledge, there is no mention regarding the fact that the
> headers assigned through the "header-args" property should not be
> applied if a block has no language identifier.

That part of the manual can be improved. Maybe something like below.

  When =<language>= identifier is omitted, the block also should not
  have =<switches>= and =<header arguments>=.  Otherwise, the first
  switch/argument will be treated as =<language>=.

Let me know if it clarifies things.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [BUG] Inconsistent org-babel tangle behaviour

[Thibaut Meyer via General discussions about Org-mode.]

> Here, a language is actually specified. The language is ":tangle" (there
> is nothing stopping anyone from creating a language name starting from
> colon).

I see. I just assumed that header arguments and switches were
"recognized" and not considered as the language if placed positionally
first.

> Src block without language could indeed be tangled in your case.

That would be indeed nice...

> However, if the :tangle value is set to something like "yes", there is
> no way or can deduce the tangle file name.

.. but I guess that this prevents us from supporting this use case.

> Usually, you can simply use "conf" or "text" language name as a
> placeholder.

It's true that once you know the behaviour, it's not that big of a deal to
do so.

>> The documentation states:
>> [Working with source code > Structure of Code Blocks]
>> "When ‘<language>’ identifier is omitted, the block also cannot have
>> ‘<switches>’ and ‘<header arguments>’."
>>
>> but, to my knowledge, there is no mention regarding the fact that the
>> headers assigned through the "header-args" property should not be
>> applied if a block has no language identifier.
>
> That part of the manual can be improved. Maybe something like below.
>
>   When =<language>= identifier is omitted, the block also should not
>   have =<switches>= and =<header arguments>=.  Otherwise, the first
>   switch/argument will be treated as =<language>=.
>
> Let me know if it clarifies things.

It does clarify things. In addition, I think that a small mention of
that "quirk" in the "Extracting Source Code" part of the manual would
also be in order. I'll send a patch shortly.

Thibaut