From: Ihor Radchenko <yantar92@posteo.net>
To: "Sebastian Wålinder" <s.walinder@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Babel results don't respect narrowing
Date: Sun, 11 Jun 2023 13:01:09 +0000 [thread overview]
Message-ID: <87sfaynofe.fsf@localhost> (raw)
In-Reply-To: <87r0qib3ri.fsf@nixos.mail-host-address-is-not-set>
[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>
prev parent reply other threads:[~2023-06-11 12:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 22:46 Babel results don't respect narrowing Sebastian Wålinder
2023-05-04 9:45 ` Ihor Radchenko
[not found] ` <87r0qib3ri.fsf@nixos.mail-host-address-is-not-set>
2023-06-11 13:01 ` Ihor Radchenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfaynofe.fsf@localhost \
--to=yantar92@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=s.walinder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).