bug#45607: 27.1; compiled replace-string breaks repeat-complex-command

[Lars Ingebrigtsen <larsi@gnus.org>]

Allen Li <darkfeline@felesatra.moe> writes:

> Interactive commands that act on the region are handled specially such
> that when repeated with `repeat-complex-command`, the repeated command
> uses the current region rather than the region used for the previous
> invocation of the command.
>
> `replace-string` does not respect this; it uses the previous region when
> repeated with `repeat-complex-command`.
>
> Note that loading `replace-string` from source (rather than byte
> compiled) fixes this problem.  So it's probably a problem with byte
> compiled commands.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I can reproduce this problem in Emacs 29?

In any case, it's because `replace-string' specifies the start/end
position in the `interactive' spec (as it should), so it lands in
`command-history', and `repeat-complex-command' just executes that.
Other commands, like `flush-lines', have pass in nil as start/end, and
then computes the start/end in the body of the function.

So this can be fixed by rewriting `replace-string' to do the same...
but surely there's a lot of commands out there that say:

  (interactive
[...]
     (list 
	   (if (use-region-p) (region-beginning))

And all of these would have the same problem.  (interactive "r") does
not, because in that case:

(defun foo (start end)
  (interactive "r")
  (message "%s %s" start end))

The following ends up there in the history:

 (foo (region-beginning) (region-end))

Does anybody know of a more general solution to this?

The reason replace-string works when it's not compiled is the because
then this ends up in command-history:

(replace-string "buffer" "foo" nil (if (use-region-p) (region-beginning)) (if (use-region-p) (region-end)) nil nil)

For some reason.

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