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

From: Stefan Monnier <[email-masked]>
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.
- If MAX-SECS/COSTS are both nil, then use the cheap implementation.
  I.e. only do the fancy diffing when one of MAX-SECS/COSTS is specified
  (could allow a `t` value to mean "do it the fancy way with default
  settings").

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).

        Stefan