Babel results don't respect narrowing

Babel results don't respect narrowing

[Sebastian Wålinder]

Hello!

When org-babel inserts results after evaluating a org-babel block, the current narrowing isn't respected.

Org searches outside of the current narrowing to find a result block, then updates that.

Here's a example to illustrate it:
```
#+CAPTION: 1. Evaluate this to narrow to the elisp block (I put :results raw here so that it's impossible for it to narrow to the first block)
#+BEGIN_SRC emacs-lisp :results raw
(narrow-to-region
 (progn
   (re-search-forward "#\\+BEGIN_SRC emacs-lisp$")
   (beginning-of-line)
   (point))
 (progn
   (re-search-forward "#\\+END_SRC")
   (next-line)
   (point)))
#+END_SRC

#+CAPTION: 2. Evaluate this
#+BEGIN_SRC emacs-lisp
(+ 1 2)
#+END_SRC

#+RESULTS:
2
```

So, if you narrow so that only the elisp (+ 1 2) src block is in view, and then evaluate it, the result that's outside of view will be updated to '3'.

This is an issue primarily with libraries that insert IDs where the results are.

Then, when the library searches for that ID it inserted in the narrowed buffer that doesn't contain the RESULTS tag, it won't be able to find it, as it's outside the view.

I believe the proper behavior to be for org-mode to create a new RESULTS tag, and insert 3 in there.

Thoughts?

Best,
Sebastian

Re: Babel results don't respect narrowing

[Ihor Radchenko]

Sebastian Wålinder <s.walinder@gmail.com> writes:

> When org-babel inserts results after evaluating a org-babel block, the current narrowing isn't respected.
>
> Org searches outside of the current narrowing to find a result block, then updates that.

Yes, it is on purpose:

2f2a80fe062df5eaacbd5bc3a34a52f6684dcee9
Author:     Nicolas Goaziou <n.goaziou@gmail.com>
AuthorDate: Wed Oct 24 17:23:20 2012 +0200
ob: Fix block evaluation in a narrowed buffer

* lisp/ob.el (org-babel-where-is-src-block-result): Insert new results
  keyword in current narrowed part of buffer, if necessary. Small
  refactoring.
(org-babel-insert-result): Do not widen buffer when new results have
to be inserted.  Therefore, results inserted after the last block of
a narrowed buffer still belong to the narrowed part of the buffer.
* testing/lisp/test-ob.el: Add tests.
* testing/lisp/test-ob-exp.el: Move test to test-ob.el

> This is an issue primarily with libraries that insert IDs where the results are.
>
> Then, when the library searches for that ID it inserted in the narrowed buffer that doesn't contain the RESULTS tag, it won't be able to find it, as it's outside the view.

May you elaborate about what kind of library you are referring to?
Please describe the actual problem you ran into.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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: Babel results don't respect narrowing

[Ihor Radchenko]

[Adding Org ML back to CC]

Sebastian Wålinder <s.walinder@gmail.com> writes:

>> May you elaborate about what kind of library you are referring to?
>> Please describe the actual problem you ran into.
> I'm using the AI API library `org-assistant` (https://github.com/tyler-dodge/org-assistant).
> The library uses org SRC blocks. When you execute a block, it adds an ID tag to the org SRC result tag using the standard org SRC execute mechanism.
> However, the library then searches for that ID in the buffer so that it can be replaced with the actual async output, but it doesn't search outside the narrowing, and so can't find it.

I'd say that org-assistant should disregard narrowing.
AFAIU, org-assistant is using some kind of custom async processing (why
not `org-babel-comint-async-register'?). If async processing is used, at
the time when result is to be inserted, the user might set arbitrary
narrowing in the buffer - it does not make sense to make things
dependent on that custom narrowing.

> This could be fixed in `org-assistant` itself, by disregarding the narrowing when searching for the ID, but I think it makes more sense to have org blocks respect the narrowing when outputting results, as the narrowing is respected by most other commands.
>
> An advantage of respecting the narrowing when searching for the result tag is that the user can save old results from being overwritten by the next execution of the SRC block by simply narrowing so that the result tag isn't in view.

Maybe. But it is too late.
Honouring narrowing in `org-babel-where-is-src-block' will be a breaking
change. At least, it is breaking a dozen of Org's own tests.

The best I can do here is documenting the current behaviour in the
docstring, to avoid confusion.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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>