GNU bug report logs -
#76313
New function `replace-region`
Previous Next
Full log
Message #91 received at 76313 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Tue, 4 Mar 2025 19:58:05 -0800
>> Cc: Philipp Stephani <phst <at> google.com>, 76313 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
>> Tassilo Horn <tsdh <at> gnu.org>
>>
>> FWIW, I think that I'd personally rather see another function than
>> complicating the `replace-region` interface just for this.
>
> And I'm of the directly opposite opinion. I think having 2 APIs for
> this is too much; adding a 3rd is overboard.
>
> I proposed some ways to avoid adding yet another API. Yes, they are
> less than ideal, but then we don't develop Emacs from scratch here, so
> compromises are unavoidable. (And it bothers me that two of the most
> prolific Emacs contributors don't see t5he terrible downsides of
> exponential explosion in the number of Emacs functions and variables.)
My proposal is to obsolete `replace-buffer-contents`, as per Stefan
Monnier's suggestion.[1] This is orthogonal to adding `replace-region`,
but means that we only have one API.
Adding `replace-region` would then bring us up to 2 APIs. This is the
same as what we have now.
To make things even clearer, we could consider renaming
`replace-region-contents` to `carefully-replace-region`, or something
along those lines. Its docstring and manual entry should emphasize it's
specialized nature. Then, we have only one API that we really recommend
for this, plus the specialized function for the rare cases when you
really need it.
(BTW, since `replace-region-contents` is currently unused in our tree,
maybe we don't even need it. OTOH, if we rename it, it shouldn't hurt
to leave it alone, in case it will be needed again in the future.)
Footnotes:
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76313#76
This bug report was last modified 75 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.