GNU bug report logs -
#76313
New function `replace-region`
Previous Next
Full log
Message #132 received at 76313 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sat, 29 Mar 2025 05:46:51 -0700
> Cc: phst <at> google.com, 76313 <at> debbugs.gnu.org, tsdh <at> gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> >> Cc: Stefan Kangas <stefankangas <at> gmail.com>, phst <at> google.com,
> >> 76313 <at> debbugs.gnu.org, tsdh <at> gnu.org
> >> Date: Fri, 28 Mar 2025 11:38:19 -0400
> >>
> >> Any chance we could consider a breaking change and force a non-nil value of
> >> one of MAX-SECS or MAX-COSTS before the function is allowed to use the
> >> costly algorithm?
> >
> > I'd prefer a completely backward-compatible change of passing a
> > special value of MAX-SECS to indicate that the potentially costly
> > algorithm is to be bypassed.
>
> We can keep trying to shoe-horn `replace-region-contents` into something
> that looks like a function intended for general use, and document it as
> such. If we go that route, I think it would make sense to make the
> change Stefan M proposes.
Can you explain why it does NOT make sense to do what I proposed? It
gives us what Stefan wanted, but avoids the backward incompatibility
(unless I'm missing something).
> Alternatively, we let it live on as a proper citizen of subr-x.el and
> consequently remove it from the manual. We've managed without
> `replace-region` for decades already, so there's no urgent need to
> elevate a design that has more than a few rough edges.
??? I'm confused: Stefan made replace-region-contents our preferred
API, and demoted replace-buffer. Are you suggesting to do the
opposite now?
This bug report was last modified 75 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.