[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36328: 26.2; Args out of range on search-and-replace of *.cc file
From: |
Juri Linkov |
Subject: |
bug#36328: 26.2; Args out of range on search-and-replace of *.cc file |
Date: |
Mon, 24 Jun 2019 22:18:53 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
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.
Usually it's enough for a function that cares about preserving match-data
to protect it from mutation.
>> 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.
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.
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, (continued)
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Jayden Navarro, 2019/06/22
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Jayden Navarro, 2019/06/22
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Alan Mackenzie, 2019/06/23
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Jayden Navarro, 2019/06/23
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Alan Mackenzie, 2019/06/23
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Juri Linkov, 2019/06/23
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Jayden Navarro, 2019/06/23
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Juri Linkov, 2019/06/24
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Jayden Navarro, 2019/06/24
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Alan Mackenzie, 2019/06/24
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file,
Juri Linkov <=
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Alan Mackenzie, 2019/06/25
- bug#36328: 26.2; Args out of range on search-and-replace of *.cc file, Juri Linkov, 2019/06/25
bug#36328: [address@hidden: Re: bug#36328: 26.2; Args out of range on search-and-replace of *.cc file], Alan Mackenzie, 2019/06/23