GNU bug report logs - #74666
31.0.50; Regression in replace-match with empty-adjacent groups

Previous Next

Full log

Message #17 received at 74666 <at> debbugs.gnu.org (full text, mbox):

From: Campbell Barton <ideasman42 <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 74666 <at> debbugs.gnu.org
Subject: Re: bug#74666: 31.0.50; Regression in replace-match with
 empty-adjacent groups
Date: Sun, 15 Dec 2024 12:10:26 +1100

On 24-12-15 3:11 AM, Stefan Monnier wrote:
>> (defun test-me (is-forward)
>>    (let ((result ""))
>>      (with-temp-buffer
>>        (insert "__B_\n")
>>        (save-match-data
>>          (set-match-data (list 2 4 2 2 2 4))
>>          (cond
>>           (is-forward
>>            (replace-match "HELLO" t t nil 1)
>>            (replace-match "WORLD" t t nil 2))
>>           (t
>>            (replace-match "WORLD" t t nil 2)
>>            (replace-match "HELLO" t t nil 1))))
>>        (setq result (buffer-substring-no-properties (point-min)
>>         (point-max))))
>>      result))
> [...]
>> In emacs 29.4 this prints:
>>
>> A: _HELLOWORLD_
>> B: _HELLOWORLD_
>>
>> In emacs 31.0.50 this prints:
>>
>> A: _WORLD_
>> B: _HELLOWORLD_
> 
> The problem is that the `set-match-data` doesn't give us any information
> about the intended inclusion relationship between the subgroups.
> 
> I agree that the behavior you see is not the one you want if it's the
> result of:
> 
>      (goto-char (point-min))
>      (looking-at "_\\(\\)\\(_B\\)")
> 
> But OTOH it is the one we want if it is the result of:
> 
>      (goto-char (point-min))
>      (looking-at "_\\(?2:\\(?1:\\)_B\\)")
> 
> We can try and guess the inclusion relationship based on circumstantial
> evidence (e.g. a "_\\(\\)\\(_B\\)" regexp is more likely than
> "_\\(?2:\\(?1:\\)_B\\)"), but that would make the code of
> `update_search_regs` tricky, with various heuristics.
> And we'll never handle all cases right unless we make significant
> changes to the match-data (and the regexp compiler) to keep track of
> inclusion relationships.
> 
> Could you give us some information about the larger context in which you
> bumped into this problem?

On the user side - I ran into this bug when decrementing numbers broke 
for me in the evil-numbers package [0]. Numbers would fail to become 
negative. Decrementing 0 would become 1.

In this case, the match data is set with `set-match-data' using 
calculated ranges.

Since this used to work I think it's reasonable to consider it a regression.

I've since committed a workaround to evil-numbers [1], although I'd 
suspect this would impact others.

[0]: https://melpa.org/#/evil-numbers
[1]: 
https://github.com/juliapath/evil-numbers/commit/f93258b706fa5cf9259e815c2d8258fcc6262804

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.