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

[Stefan Monnier]

>> > What are you trying to understand?
>> 
>> Why you're saying that in
>> 
>>     ;; `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)))
>> 
>> it is not true that
>> 
>>     and (nth 0 match-data) == (match-beginning 0), no?
>
> Because of markers vs positions, as I've tried to explain.  The
> difference is minor, of course.

But `goto-char` doesn't care about that difference, and no buffer will
be changed between the time we call `match-data` (thus creating the
markers) and the time we use those markers, so going through markers is
just extra work for no benefit.

IOW, I still don't understand how "markers vs positions" is relevant in

    (when backward (goto-char (nth 0 match-data)))

>> > What my kludge did is simply use a marker, so the adjusted position is
>> > not clobbered.
>> 
>> I don't see that.  E.g. if you change your code from
>> 
>>     (set-match-data (list (car match-data) (nth 1 (match-data))))
>> to
>>     (set-match-data (list (car match-data) (nth 1 (match-data t))))
>> 
>> it fixes the problem just as well, AFAICT.
>
> Yes, but match-data (the function) returns updated positions, which
> behave like markers across the replace-match call.

But the positions have already been updated.  So

    (match-data t)

would also return those updated positions, even though it doesn't
use markers.


        Stefan