Subject: Re: bug#76313: New function `replace-region`

From: Eli Zaretskii <[email-masked]>
Date: Sat, 29 Mar 2025 16:05:00 +0300

> From: Stefan Kangas <[email-masked]>
> Date: Sat, 29 Mar 2025 05:46:51 -0700
> Cc: [email-masked], [email-masked], [email-masked]
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> From: Stefan Monnier <[email-masked]>
> >> Cc: Stefan Kangas <[email-masked]>,  [email-masked],
> >>   [email-masked],  [email-masked]
> >> 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?