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

From: Stefan Monnier <[email-masked]>
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).

`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:

    (replace-region FROM TO REPLACEMENT &optional INHERIT CAREFULLY)

- REPLACEMENT can be a string or a buffer object (not a buffer name!).
  I'd drop support for `replace-region-contents`s function
  because one can just as easily run the function before calling
  `replace-region(-contents)` (which may also save us from building
  a closure).
-  INHERIT would specify whether to "insert-and-inherit" (used by
  `minibuffer--replace`).
- CAREFULLY if non-nil requests a costly replacement which minimizes
  impact on markers and such.  It can be a symbol or a list (MAX-SECS
  MAX-COSTS), tho I hate that ill-defined MAX-COSTS thingy, so if we
  could replace it with something better defined that would be sweet.
- I'd make it return nil since it seems that the return value of
  `replace-buffer-contents` is not used anywhere (well, except in
  `files-tests-revert-buffer-with-fine-grain` where we could replace it
  with a test that some marker was indeed properly preserved rather
  than blindly believing the return value of `revert-buffer-with-fine-grain`).

I can do that.

        Stefan