bug#67124: 26.3; query-replace Arg out of range with comma option (at end-buffer)

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> Ok, I'll wait for the next release, Thank you.

I think you might be able to use the following as a temporary fix which
should also be harmless when not useful:

    (advice-add 'replace-match-maybe-edit :before
                #'my-workaround-for-bug67124)
    (defun my-workaround-for-bug67124 (&optional _newtext _fixedcase
                                       _literal _noedit match-data
                                       &rest _)
      (when (and (integerp (car-safe match-data))
                 (integerp (car-safe (cdr-safe match-data))))
        ;; Make sure the "end" part of `match-data` is a marker
        ;; so it can't be pointing outside the buffer no matter
        ;; what the replacement does.
        (setf (nth 1 match-data)
              (copy-marker (nth 1 match-data)))))


-- Stefan


> Il 13/11/23 15:45, Dmitry Gutov ha scritto:
>> On 13/11/2023 16:38, Eli Zaretskii wrote:
>>>> Date: Mon, 13 Nov 2023 16:21:43 +0200
>>>> Cc:67124@debbugs.gnu.org
>>>> From: Dmitry Gutov<dmitry@gutov.dev>
>>>>
>>>> On 13/11/2023 16:06, Eli Zaretskii wrote:
>>>>> [Please use Reply All to reply, so that the bug tracker is CC'ed.]
>>>>>> Date: Sun, 12 Nov 2023 23:44:43 +0100
>>>>>> From: Gabriele Nicolardi<gabriele@medialab.sissa.it>
>>>>>>
>>>>>> I tested the patch on the MWE I sent to you. Thanks!
>>>>>>
>>>>>> Now I'm not sure what I should do. I write elisp code used by
>>>>>> a production team. We use Emacs to
>>>>>> format LaTeX documents of scientific papers. I don't control which
>>>>>> version of Emacs my
>>>>>> collaborators use. Do you have any suggestions?
>>>>> I guess either wait for the next Emacs release or build your own
>>>>> Emacs?
>>>> I haven't examined the exact problem, but in such cases some people also
>>>> either have workarounds in their own code, or supply "advices" for the
>>>> core functions that work around the problem there.
>>> Then maybe a simple replacement for the offending function, defined in
>>> an init file, would also be a possible solution?
>>
>> Sure. Though it might be more reliable with advice, since they don't
>> depend on the loading order.
>>
>> The problems I had in mind would be more subtle and independent of the
>> choice between these two methods. Stefan's latest patch includes changes
>> in search.c, so it might be difficult to work around in just Lisp. Again,
>> I haven't examined the problem itself.