bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#74666: 31.0.50; Regression in replace-match with empty-adjacent grou


From: Campbell Barton
Subject: bug#74666: 31.0.50; Regression in replace-match with empty-adjacent groups
Date: Sun, 15 Dec 2024 12:10:26 +1100
User-agent: Mozilla Thunderbird



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









reply via email to

[Prev in Thread] Current Thread [Next in Thread]