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

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Sat, 15 Feb 2025 22:19:02 UTC

Severity: normal

Tags: patch

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76313 <at> debbugs.gnu.org, stefankangas <at> gmail.com, tsdh <at> gnu.org
Subject: bug#76313: New function `replace-region`
Date: Sun, 30 Mar 2025 11:30:18 -0400
>> > I'd prefer a completely backward-compatible change of passing a
>> > special value of MAX-SECS to indicate that the potentially costly
>> > algorithm is to be bypassed.
>> We already have that: pass a 0 for MAX-SECS.
> So we should probably mention this in the documentation?

I think that's already implied by the doc of MAX-SECS:

    The MAX-SECS argument, if given, defines a hard limit on the time used
    for comparing the buffers.  If it takes longer than MAX-SECS, the
    function falls back to a plain ‘delete-region’ and
    ‘insert-buffer-substring’.  (Note that the checks are not performed
    too evenly over time, so in some cases it may run a bit longer than
    allowed).

>> IOW, if you have code that uses
>> 
>>     (replace-region-contents BEG END SOURCE 0)
>> 
>> and you change it to:
>> 
>>     (replace-region-contents BEG END SOURCE 0.1)
>> 
>> thinking "oh, I can afford to spend a bit more time here, let's
>> enable the fancy diff algorithm", you may end up breaking your code.
>
> So maybe these subtleties should be described in the manual?  And if
> the caller doesn't care, or has point in a place that won't bump into
> these issues, then replace-region-contents can still be used as a Lisp
> API to replace_region?

I feel like this is setting up a trap for the average coder.

> For example, a loop like you describe above could carefully place
> point before each call to re-search-forward, to avoid the
> problems, no?

Of course, the careful coder will find a solution.

I still can't understand why you're so opposed to having
2 different functions.

In comparison, we have:

On the insertion side:
  - insert
  - insert-and-inherit
  - insert-before-markers
  - insert-buffer-substring
  - insert-buffer
  - insert-into-buffer
On the deletion side:
  - delete-region
  - delete-char
  - delete-and-extract-region
  - erase-buffer

I mean, I understand that the above functions all cover somewhat
different calling cases [side note: `replace-region-contents` tries to
unify them], whereas `replace-region` and `replace-region-carefully`
would be called with the same arguments to "do the same".

But I don't think coders would have any difficulty understanding that
one of them is the low-level, deterministic, O(N) primitive while the
other is a "smart" O(almost N²) alternative, with a much larger constant
factor, which decomposes the replacement into smaller calls to
`replace-region`, using heuristics, with the uncertainty this entails.


        Stefan





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.