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

[Gabriele Nicolardi <gabriele@medialab.sissa.it>]

Il 16/11/23 15:45, Stefan Monnier ha scritto:
>> 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

Thank you! I'll study the code and l'll try it!

Gabriele

>
>> 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.