[Top][All Lists]

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

Re: Looking at function

From: Juri Linkov
Subject: Re: Looking at function
Date: Tue, 12 Jul 2022 10:50:28 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu)

>>> Do we have a clear understanding of the idea behind this looking-at call?
>>> The comment says:
>>>       ;; Otherwise, if matching a regular expression, do the next
>>>       ;; match now, since the replacement for this match may
>>>       ;; affect whether the next match is adjacent to this one.
>>>       ;; If that match is empty, don't use it.
>>> What happens if there are multiple adjacent matches in a row, not just 2?
>>> I suppose the replacement could be performed for the first one, then the
>>> next one is "popped" becoming the current and looking-at is called again
>>> near its end?

Actually, this is how it worked until now.

>>> If so, perhaps a good alternative is to stop caring about whether those
>>> matches are adjacent and always store the latest two matches, whether they
>>> are next to each other or not.

And this is how it's implemented by the patches in bug#14013 and bug#53758.

>> The sole purpose of this "do the next match now" hack
>> is to handle a special use case that is tested
>> in test/lisp/replace-tests.el:
>>      ;; Test case from commit 5632eb272c7
>>      ("a a a " "C-M-% \\ba SPC RET c RET !" "ccc") ; not "ca c"
>>      ;; Test case from commit 5632eb272c7
>>      ("a a a " "\\ba " "c" nil t nil nil nil nil nil nil nil "ccc") ; not 
>> "ca c"
> All right. So it seems the idea of keeping references to the two latest can
> work.
> No idea how big the changes will have to be, though.

Shouldn't keeping only one reference be sufficient?

reply via email to

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