GNU bug report logs - #76313
New function `replace-region`

Previous Next

Full log

Message #38 received at 76313 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76313 <at> debbugs.gnu.org
Subject: Re: bug#76313: New function `replace-region`
Date: Tue, 18 Feb 2025 14:25:17 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 76313 <at> debbugs.gnu.org
> Date: Mon, 17 Feb 2025 15:55:04 -0500
> 
> >> So does that mean you're OK with my new `replace-region`, and that
> >> I should open a new bug-report with a proposal for how to merge
> >> `replace-region-contents` and `replace-buffer-contents`?
> >> 
> >> Or something else?
> >
> > You suggested to merge replace-region-contents with
> > replace-buffer-contents when replace-region was not on the table at
> > all.  I'm still not sure we want a 3rd API for this purpose.
> 
> I just want a simple function which does the same as
> `insert+delete-region`, just as efficiently, without having to think
> about which way is best (should I delete first, or insert first?
> If I insert first, should I insert at FROM, or at TO, or in the
> middle?  You can find pretty much all variations out there, several
> times with comments showing that the coders did have to waste time
> thinking about it).

How come we never needed it until now, even though insdel.c can
replace buffer text since day one?  And are you sure that the way you
implement it by calling replace_region, this will produce exactly the
variation that everyone wants?

I thought at some point you suggested allowing to extend the
REPLACE-FN argument of replace-region-contents to be a string, and I
agreed to that (had the same idea, actually, while reading your OP).
But now you are going back to basically your original proposal? why?

> `replace-buffer/region-contents` is not a valid answer because it's
> a lot more costly.  Do you want me to merge them all into a single
> monster `replace-region` function and mark the other two as obsolete:

No, but how about

 (replace-buffer-contents SOURCE &optional MAX-SECS MAX-COSTS CHEAP-AND-RECKLESS)

where, if CHEAP-AND-RECKLESS is non-nil, we call replace_region
disregarding what will that do to markers and overlays?  If you want
to support INHERIT, CHEAP-AND-RECKLESS could be also non-nil and non-t
to indicate that.  I can live with that; at least we stay with the
same 2 APIs, of which one is implemented on top of the other.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.