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

[Lars Ingebrigtsen <larsi@gnus.org>]

Ren Victor <victorhge@gmail.com> writes:

> In `replace_range', the point is also relocated.  I am not sure why it has
> to be moved again just before returning from `replace-match'.

I can reproduce this error on Emacs 28.

The problem seems to be this in Freplace_match?  

  /* 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?

Anyway, removing that move makes the suggested test not fail, but it
leads to a bunch of other tests failing, so it's doing something right,
at least.

However, just before that, there's this:

  /* 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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no