Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Ihor Radchenko]

Tom Gillespie  writes:

> PS A new issue arises however caused by
> 487f39efa68fa2d857f8d446d1c4b3a3b3e3f482,
> which is that it is now confusing  to get the {{{results(=value=)}}}
> macro without verbatim which is what :results drawer meant in
> that context. I expect that change will break things for a number
> of people beyond myself. A bit of reading the code revealed that
> setting :wrap t makes it possible to get {{{results(value)}}} again,
> but line 2647 [1] seems to indicate that drawer is an expected
> and valid value for inline :results.
>
>
> 1.
>((or (member "drawer" result-params)
> ;; Stay backward compatible with <7.9.2
> (member "wrap" result-params))
> (goto-char beg) (when (org-at-table-p) (org-cycle))
> (funcall wrap ":results:" ":end:" 'no-escape nil
>  "{{{results(" ")}}}"))

It was a slip when the patch was applied.
See the table of :results params vs. expected output that Nicolas
provided in
https://list.orgmode.org/orgmode/87zjbqrapy@nicolasgoaziou.fr/

Or maybe I miss something.

May you please explain more about {{{results(=value=)}}} problem?
Isn't it sufficient to do src_elisp[:results verbatim]{'value} 
{{{results(=value=)}}}?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Ihor Radchenko]

Tom Gillespie  writes:

>> It was a slip when the patch was applied.
>> May you please explain more about {{{results(=value=)}}} problem?
>> Isn't it sufficient to do src_elisp[:results verbatim]{'value} 
>> {{{results(=value=)}}}?
>
> The issue is the opposite I think. Currently the default value (i.e. absent)
> for :results does not produce {{{results(value)}}} as suggested, and instead
> producers {{{results(=value=)}}}. ...
>
> It looks like there used to be an option [:results wrap] which was deprecated
> a _very_ long time ago. [:results drawer] replaced that, and while there is
> some confusion about the name (because there is no actual drawer in an
> inline result) the behavior was meant to replace the old :results wrap 
> behavior
> where the name does make sense since {{{results(value)}}} do "wrap" the value.

Thanks!
In addition, the docstring of `org-babel-insert-result' says

drawer -- results are added directly to the Org file as with
  "raw", but are wrapped in a RESULTS drawer or results
  macro, allowing them to later be replaced or removed
  automatically.

But not in the manual:

‘drawer’
 Result wrapped in a ‘RESULTS’ drawer.  Useful for containing ‘raw’
 or ‘org’ results for later scripting and automated processing.
 Usage example: ‘:results value drawer’.

Also, removal of :results wrap seemingly missed the inline src block use
case: https://list.orgmode.org/orgmode/876271cjpb@bzg.ath.cx/

Bastien, may you comment?

:results drawer feels confusing for inline src blocks.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Tom Gillespie]

> It was a slip when the patch was applied.
> See the table of :results params vs. expected output that Nicolas
> provided in
> https://list.orgmode.org/orgmode/87zjbqrapy@nicolasgoaziou.fr/
>
> Or maybe I miss something.
>
> May you please explain more about {{{results(=value=)}}} problem?
> Isn't it sufficient to do src_elisp[:results verbatim]{'value} 
> {{{results(=value=)}}}?

The issue is the opposite I think. Currently the default value (i.e. absent)
for :results does not produce {{{results(value)}}} as suggested, and instead
producers {{{results(=value=)}}}. This means that without :results drawer
there isn't an obvious way to get {{{results(value)}}} because you can't e.g.
use [:results default], or if a user overrides the default value for
inline header
args at file level then they have no way to reset to the default.

It looks like there used to be an option [:results wrap] which was deprecated
a _very_ long time ago. [:results drawer] replaced that, and while there is
some confusion about the name (because there is no actual drawer in an
inline result) the behavior was meant to replace the old :results wrap behavior
where the name does make sense since {{{results(value)}}} do "wrap" the value.

I think that covers it, but let me know if something doesn't make sense. Best,
Tom

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Tom Gillespie]

Confirming fixed. Thanks!

PS A new issue arises however caused by
487f39efa68fa2d857f8d446d1c4b3a3b3e3f482,
which is that it is now confusing  to get the {{{results(=value=)}}}
macro without verbatim which is what :results drawer meant in
that context. I expect that change will break things for a number
of people beyond myself. A bit of reading the code revealed that
setting :wrap t makes it possible to get {{{results(value)}}} again,
but line 2647 [1] seems to indicate that drawer is an expected
and valid value for inline :results.


1.
   ((or (member "drawer" result-params)
;; Stay backward compatible with <7.9.2
(member "wrap" result-params))
(goto-char beg) (when (org-at-table-p) (org-cycle))
(funcall wrap ":results:" ":end:" 'no-escape nil
 "{{{results(" ")}}}"))

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Ihor Radchenko]

Tom Gillespie  writes:

>> org-element-at-point is not supposed to return objects. So, there is no
>> problem here.
>
> Right. My original issue description is wrong for this part. It seems that
> org-babel-get-src-block-info returns nil when immediately before the start
> of the ala |src_ in #+caption: but will return non-nil in other contexts. In
> the #+caption: it will only work if the cursor is past the s ala s|rc_. Or
> if in non evil mode when the cursor is on the s in src_.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=54c09c84e
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9fd547dd3

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Tom Gillespie]

I have tested this again against bugfix, the issue is still present
when the cursor is on the s in #+caption: src_. Best,
Tom

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Tom Gillespie]

> org-element-at-point is not supposed to return objects. So, there is no
> problem here.

Right. My original issue description is wrong for this part. It seems that
org-babel-get-src-block-info returns nil when immediately before the start
of the ala |src_ in #+caption: but will return non-nil in other contexts. In
the #+caption: it will only work if the cursor is past the s ala s|rc_. Or
if in non evil mode when the cursor is on the s in src_.

I can workaround the issue for now with forward-char, but it seems there
is an off-by-one error involving #+caption: followed immediately by src_,
if there is anything in between #+caption: and src_ then it works correctly.

> Also, C-c C-c works for me on bugfix in the above example.

Hrm, I can't get it to work, but I haven't done a proper control that
loads only bugfix and nothing else. Will report back if I get it to work.

Re: [BUG] inline src blocks in caption of not-inline src blocks do not execute

[Ihor Radchenko]

Tom Gillespie  writes:

> This one fails to work with C-c C-c, and org-element-at-point returns
> the bash src block below.
>
> #+caption: src_elisp[:results drawer]{"I've made a horrible mistake"}
> #+begin_src bash
> echo OH NO
> #+end_src

org-element-at-point is not supposed to return objects. So, there is no
problem here.

Also, C-c C-c works for me on bugfix in the above example.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] inline src blocks in caption of not-inline src blocks do not execute

[Tom Gillespie]

I've found a bug where inline source blocks cannot be executed and
org-element cannot find/parse them if they are in #+captions: where
the caption is affiliated with a not-inline source block. Example
below. Best,
Tom

Issue present in:
Org mode version 9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)
GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version
1.17.8) of 2023-08-0

This inline src block works with C-c C-c.

#+caption: src_elisp[:results drawer]{"All good!"} {{{results(All good!)}}}
[[file:./images/happy-figure.png]]

This one fails to work with C-c C-c, and org-element-at-point returns
the bash src block below.

#+caption: src_elisp[:results drawer]{"I've made a horrible mistake"}
#+begin_src bash
echo OH NO
#+end_src