bug#42424: 27.0.90; replace-match: point is NOT left at the end of replacement

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 17 Oct 2020 11:49:42 +0200
> Cc: 42424@debbugs.gnu.org
> 
>   /* Put point back where it was in the text, if possible.  */
>   TEMP_SET_PT (clip_to_bounds (BEGV, opoint + (opoint <= 0 ? ZV : 0), ZV));
>   /* Now move point "officially" to the start of the inserted replacement.  */
>   move_if_not_intangible (newpoint);
> 
> Uhm...  is that comment wrong?  Aren't we moving point to the end of the
> inserted replacement?

Yes, it should say "end", not "start".

>   /* The replace_range etc. functions can trigger modification hooks
>      (see signal_before_change and signal_after_change).  Try to error
>      out if these hooks clobber the match data since clobbering can
>      result in confusing bugs.  Although this sanity check does not
>      catch all possible clobberings, it should catch many of them.  */
>   if (! (search_regs.num_regs == num_regs
> 	 && search_regs.start[sub] == newstart
> 	 && search_regs.end[sub] == newpoint))
>     error ("Match data clobbered by buffer modification hooks");
> 
> So replace_match is already signalling some errors on buffer
> modification hooks, but not here.  So is this a bug or just something
> that should be documented better?

Personally, I wonder what was expected here.  If the modification
hooks modify the replaced text behind our back, how can the Lisp
program which does that expect to have point where it belongs?  Am I
missing something?