[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>
