[Adding Org ML back to CC]

Sebastian Wålinder <s.walin...@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>

Reply via email to