GNU bug report logs -
#74276
30.0.90; undo does not account for overlays now that markers are not used
Previous Next
To reply to this bug, email your comments to 74276 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
karthikchikmagalur <at> gmail.com, bug-gnu-emacs <at> gnu.org
:
bug#74276
; Package
emacs
.
(Sat, 09 Nov 2024 06:43:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
James Thomas <jimjoe <at> gmx.net>
:
New bug report received and forwarded. Copy sent to
karthikchikmagalur <at> gmail.com, bug-gnu-emacs <at> gnu.org
.
(Sat, 09 Nov 2024 06:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
- 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)
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74276
; Package
emacs
.
(Sat, 09 Nov 2024 08:14:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 74276 <at> debbugs.gnu.org (full text, mbox):
> Cc: karthikchikmagalur <at> 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 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74276
; Package
emacs
.
(Sat, 09 Nov 2024 15:07:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 74276 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74276
; Package
emacs
.
(Sat, 09 Nov 2024 15:53:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 74276 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: James Thomas <jimjoe <at> gmx.net>, 74276 <at> debbugs.gnu.org,
> karthikchikmagalur <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74276
; Package
emacs
.
(Thu, 14 Nov 2024 15:37:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 74276 <at> debbugs.gnu.org (full text, mbox):
>> > 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)))))))
🙂
This bug report was last modified 212 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.