bug#36328: 26.2; Args out of range on search-and-replace of *.cc file

[Alan Mackenzie]

Hello, Juri.

On Mon, Jun 24, 2019 at 22:18:53 +0300, Juri Linkov wrote:
> Hello, Alan.

> >> I think first we should try to narrow down the source of this match
> >> data leak.

> > Is there really such a thing as a match data leak?  I don't think
> > there's any convention that the match data are preserved over large
> > bits of code, particularly when different libraries are involved.
> > There is nothing documented in the Elisp manual that I can see.

> Yes, it seems such match-data leak is considered at least undesirable.
> I remember efforts to replace string-match with string-match-p in
> potentially unsafe places and to wrap more code in save-match-data.
> But I guess such efforts are futile since this task is endless.

I think so, too.  I remembered being puzzled in my early Emacs days,
wondering whether the save-match-data should go in the function which
messes it up, or the function which cares about it.

> Usually it's enough for a function that cares about preserving
> match-data to protect it from mutation.

I now think this is the best place to put save-match-data.

> >> Then we could decide what is the best solution.  Currently I see no
> >> such place in isearch-lazy-highlight-new-loop that calls external
> >> code.

> > isearch-lazy-highlight-new-loop calls (sit-for 0), which calls
> > redisplay, which calls font locking.

> You are right that it's too much to expect that the match-data will be
> preserved after redisplay, and we can't find and fix all places that
> change match-data, so save-match-data needs be added to perform-replace
> somewhere to protect match-data.

Yes, I think so.

> Since (sit-for 0) is unsafe for match-data, the first candidate to be
> wrapped in save-match-data is (sit-for 0) itself in
> isearch-lazy-highlight-new-loop.

> But perhaps more correct would be to use save-match-data in the same
> function that cares about preserving its match-data, so the second
> candidate to use save-match-data is perform-replace.  Then the need
> of using save-match-data will be self-evident for everyone who will
> look at the code in perform-replace: here we use match-data, and here
> we protect it in the same function.

My feeling is that perform-replace (or, possibly, replace-highlight) is
the best place to put a save-match-data.

-- 
Alan Mackenzie (Nuremberg, Germany).