bug#74276: 30.0.90; undo does not account for overlays now that markers are not used

bug#74276: 30.0.90; undo does not account for overlays now that markers are not used

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

- emacs -Q
- Type: abcdef
- C-a
- M-: (overlay-put (make-overlay (point) (+ (point) 3)) 'face 'highlight)
- Mark the text 'bcd' and delete it
- M-x undo (does not restore overlay correctly)

(The solution seems to me to be for undo to also store the overlay,
adjustment, and whether left, right or both boundaries are involved, and
use it)

--

bug#74276: 30.0.90; undo does not account for overlays now that markers are not used

[Eli Zaretskii]

> Cc: karthikchikmagalur@gmail.com
> Date: Sat, 09 Nov 2024 12:11:50 +0530
> From:  James Thomas via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> - emacs -Q
> - Type: abcdef
> - C-a
> - M-: (overlay-put (make-overlay (point) (+ (point) 3)) 'face 'highlight)
> - Mark the text 'bcd' and delete it
> - M-x undo (does not restore overlay correctly)
> 
> (The solution seems to me to be for undo to also store the overlay,
> adjustment, and whether left, right or both boundaries are involved, and
> use it)

This didn't work with the old implementation of overlays, either.  I
just tested in Emacs 25 and I see the same results there.

Stefan, does undo restore overlays, and if so, how?  I don't see
anything pertinent in the Undo section of the ELisp manual except the
reference to markers (which overlays don't have anymore).  Did that
ever work, and if so, how?  And how should it work now?

bug#74276: 30.0.90; undo does not account for overlays now that markers are not used

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

> Stefan, does undo restore overlays, and if so, how?

No, I don't think `undo` has ever tried to restore overlays.
But it does attempt to restore marker positions, so I guess there can be
cases where the switch to itree has caused overlays' boundaries to be
restored less well than before.


        Stefan

bug#74276: 30.0.90; undo does not account for overlays now that markers are not used

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: James Thomas <jimjoe@gmx.net>,  74276@debbugs.gnu.org,
>   karthikchikmagalur@gmail.com
> Date: Sat, 09 Nov 2024 10:05:51 -0500
> 
> > Stefan, does undo restore overlays, and if so, how?
> 
> No, I don't think `undo` has ever tried to restore overlays.
> But it does attempt to restore marker positions, so I guess there can be
> cases where the switch to itree has caused overlays' boundaries to be
> restored less well than before.

Well, in this particular recipe Emacs 29 and 30 behave exactly like
Emacs 25, do at least in this case there was no regression.

But maybe we should add to undo the capability of restoring the
overlays.

bug#74276: 30.0.90; undo does not account for overlays now that markers are not used

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

>> > Stefan, does undo restore overlays, and if so, how?
>> No, I don't think `undo` has ever tried to restore overlays.
>> But it does attempt to restore marker positions, so I guess there can be
>> cases where the switch to itree has caused overlays' boundaries to be
>> restored less well than before.
> Well, in this particular recipe Emacs 29 and 30 behave exactly like
> Emacs 25, do at least in this case there was no regression.

Which suggests that maybe the code we have to save/restore the position of
markers in `buffer-undo-list` doesn't(didn't?) really do its job.

> But maybe we should add to undo the capability of restoring the
> overlays.

Maybe.


        Stefan


PS: Reading the `record_marker_adjustments` in Emacs-28, it seems that
this code would happily add to the `buffer-undo-list` markers that were
"internal" to overlays.  That reminds me of a discussion many years ago
where I suggested we add functions to return the begin/end markers of an
overlay so that ELisp code could use `set-marker-insertion-type` to
change the insertion type of the beginning/end of an overlay (which is
currently otherwise fixed at creation).  This was rejected because
exposing such internals would be undesirable (e.g. making
backward-incompatible the change we implemented in Emacs-29) and risky
(allowing inconsistencies like overlays whose beg and end don't point to
the same buffer).  It turns out that such functions could have been
hacked all along in ELisp by (ab)using this `record_marker_adjustments`
code:

    (defun overlay-markers (ol)
      "Return the two markers of an overlay as (BEG . END)."
      (with-temp-buffer
        (insert "aa")
        (let ((beg (point))
              (_ (insert "bbb"))
              (end (point)))
          (insert "cccc")
          (move-overlay ol beg end (current-buffer))
          (let ((buffer-undo-list ()))
            (delete-region (point-min) (point-max))
            (cons (car (rassq -2 buffer-undo-list))
                  (car (rassq -5 buffer-undo-list)))))))

🙂