bug#60143: 29.0.60; command `undo-redo` don't restore cursor position

bug#60143: 29.0.60; command `undo-redo` don't restore cursor position

[yinz Liu]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

aaaa ! bbbb @ cccc #


1. when cursor at position "#", call `undo', cursor jump to "@"

2. when cursor at position "@", call `undo-redo', text "cccc" restore,

   but cursor still remain in "@", don't move to "#".


my workaround fow now:


in function primitive-undo
<https://github.com/emacs-mirror/emacs/blob/149e6e03b3f860c3d78031bf3377d8a4c99a7a64/lisp/simple.el#L3622-L3624>
 :


change L3624 to : `(goto-char (+ pos (length string)))`

[-- Attachment #2: Type: text/html, Size: 2823 bytes --]

bug#60143: 29.0.60; command `undo-redo` don't restore cursor position

[Eli Zaretskii]

> From: yinz Liu <liuyinz95@gmail.com>
> Date: Sat, 17 Dec 2022 09:42:28 +0800
> 
> aaaa ! bbbb @ cccc #
> 
> 1. when cursor at position "#", call `undo', cursor jump to "@"
> 
> 2. when cursor at position "@", call `undo-redo', text "cccc" restore,
>    but cursor still remain in "@", don't move to "#".
> 
> my workaround fow now:
> 
> in function primitive-undo :
> 
> change L3624 to : `(goto-char (+ pos (length string)))`

That code is there for almost 10 years, and before that the C
implementation did the same.  The way the code is written, viz.:

               (goto-char pos)
               (insert string)
               (goto-char pos))

it is clear that the second goto-char is on purpose, since if we
delete it, we get the effect that you want; no need to goto anywhere
else, because 'insert' leaves point after the inserted text.

So I very much hesitate to change this.  Stefan, any comments? do you
happen to know why we return point to before the insertion?

bug#60143: 29.0.60; command `undo-redo` don't restore cursor position

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> So I very much hesitate to change this.  Stefan, any comments?

Changing that code is likely wrong, indeed.  If the undo doesn't get
you where you expected, it should usually be changed by adding an
additional record to the undo log.

That "record" is a simple integer indicating the position of point at
that moment (citing `C-h o buffer-undo-list`):

    An entry of the form POSITION indicates that point was at the buffer
    location given by the integer.  Undoing an entry of this form places
    point at POSITION.

As for whether we should add such a record in the OP's scenario, and how
to do that, I haven't looked at his scenario in enough detail to have
much to say about it.


        Stefan

bug#60143: 29.0.60; command `undo-redo` don't restore cursor position

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yinz Liu <liuyinz95@gmail.com>,  60143@debbugs.gnu.org
> Date: Sun, 18 Dec 2022 20:42:31 -0500
> 
> > So I very much hesitate to change this.  Stefan, any comments?
> 
> Changing that code is likely wrong, indeed.  If the undo doesn't get
> you where you expected, it should usually be changed by adding an
> additional record to the undo log.
> 
> That "record" is a simple integer indicating the position of point at
> that moment (citing `C-h o buffer-undo-list`):
> 
>     An entry of the form POSITION indicates that point was at the buffer
>     location given by the integer.  Undoing an entry of this form places
>     point at POSITION.
> 
> As for whether we should add such a record in the OP's scenario, and how
> to do that, I haven't looked at his scenario in enough detail to have
> much to say about it.

I don't think we record position of point before deletion.  Which is
why 'undo' in that scenario also ends up with point before the
recovered deletion.

bug#60143: 29.0.60; command `undo-redo` don't restore cursor position

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii [2022-12-19 05:35:49] wrote:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: yinz Liu <liuyinz95@gmail.com>,  60143@debbugs.gnu.org
>> Date: Sun, 18 Dec 2022 20:42:31 -0500
>> 
>> > So I very much hesitate to change this.  Stefan, any comments?
>> 
>> Changing that code is likely wrong, indeed.  If the undo doesn't get
>> you where you expected, it should usually be changed by adding an
>> additional record to the undo log.
>> 
>> That "record" is a simple integer indicating the position of point at
>> that moment (citing `C-h o buffer-undo-list`):
>> 
>>     An entry of the form POSITION indicates that point was at the buffer
>>     location given by the integer.  Undoing an entry of this form places
>>     point at POSITION.
>> 
>> As for whether we should add such a record in the OP's scenario, and how
>> to do that, I haven't looked at his scenario in enough detail to have
>> much to say about it.
>
> I don't think we record position of point before deletion.

I think we do, at least sometimes:

    record_delete (ptrdiff_t beg, Lisp_Object string, bool record_markers)
    {
      [...]
      record_point (beg);


-- Stefan