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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 16 Nov 2023 16:55:39 +0200

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Thu, 16 Nov 2023 09:29:22 -0500
> 
> >> >    ;; `replace-match' leaves point at the end of the replacement text,
> >> >    ;; so move point to the beginning when replacing backward.
> >> >    (when backward (goto-char (nth 0 match-data)))
> >> 
> >> and (nth 0 match-data) == (match-beginning 0), no?
> > See above: not exactly.
> 
> I believe the numerical value of (nth 0 match-data) will be the same at
> this point as that of (nth 0 (match-data)) because we just passed that
> very value to `set-match-data`, and that is always equal
> (numerically) to (match-beginning 0).
> Since the only thing we do with that value is pass it immediately to
> `goto-char`, it makes no difference if it's a marker or an integer, no?
> 
> What am I missing?

What are you trying to understand?  The cause of the bug is that we
force the match data back to the buffer position before the replace.
As long as that is not removed, the bug will remain.

What my kludge did is simply use a marker, so the adjusted position is
not clobbered.