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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76313 <at> debbugs.gnu.org
Subject: bug#76313: New function `replace-region`
Date: Sun, 16 Feb 2025 21:30:41 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 76313 <at> debbugs.gnu.org
> Date: Sun, 16 Feb 2025 12:17:04 -0500
> 
> >> So I suggest the patch below.  Comments?  Objections?
> > What's wrong with replace-buffer-contents or replace-region-contents?
> 
> Yeah, I'm not super happy about that situation, but here are my reasons:
> 
> - On the API side: They're inconvenient replacements because they require
>   either changing the narrowing or wrapping the replacement string into
>   a closure.  Not the end of the world, but AFAICT, `replace-region` is
>   a quite common operation (the patch I sent only replaces a couple of
>   use-cases, but I know there are much more).
> 
> - On the implementation side: They are significantly more expensive (fancier).
> 
> Maybe we should merge some of them.  E.g. we could merge my
> proposed `replace-region` with `replace-region-contents` as follow:
> 
> - Allow REPLACE-FN to be a string rather than a function.

I immediately thought of this extension when I saw your proposal.

> I'm not sure it'd be a good idea, tho: `replace-region-contents` is
> a "heavy" operation, involving narrowing and another buffer, whereas
> `replace-region` is meant to be a low-level operation (if we implement
> it in C, we could arguably use it as *the* low-level operation and
> define `insert` and `delete-region` on top of it).

On the downside, we already have 2 APIs for this, so having a 3rd one
will only make the confusion more prominent.  Who, apart of you and
maybe me, will know or remember that those two are "heavy" whereas the
3rd one isn't, especially given that replace-buffer-contents is
implemented in C?  And how to apply that knowledge to any concrete use
case?

Also, if someone wants a "simple" implementation that doesn't care
about being destructive and clobbering markers, properties, etc., why
can't they indeed do the delete-region + insert dance?

Previous Next

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