From: Stefan <monnier@iro.umontreal.ca>
To: Barry OReilly <gundaetiapo@gmail.com>
Cc: 16818@debbugs.gnu.org
Subject: bug#16818: Acknowledgement (Undo in region after markers in undo history relocated)
Date: Mon, 17 Mar 2014 20:02:43 -0400 [thread overview]
Message-ID: <jwva9co2xs4.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <CAFM41H2fmREiVOm6Vh4KGeRLSLM99cMbsHKdHn_86p_dj=1yLw@mail.gmail.com> (Barry OReilly's message of "Mon, 17 Mar 2014 19:05:34 -0400")
>> The primitive-undo fix should be safe enough for 24.4, so if you
>> want to code this up and install it, feel free.
> I have attached the patch for this, which I'll install if nothing
> comes up from review.
Thanks. A few comments below.
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2229,6 +2229,7 @@
(did-apply nil)
(next nil))
(while (> arg 0)
+ (let (del-pos)
(while (setq next (pop list)) ;Exit inner loop at undo boundary.
;; Handle an integer by setting point to that value.
(pcase next
@@ -2289,6 +2290,7 @@
(when (let ((apos (abs pos)))
(or (< apos (point-min)) (> apos (point-max))))
(error "Changes to be undone are outside visible portion of buffer"))
+ (setq del-pos pos)
(if (< pos 0)
(progn
(goto-char (- pos))
@@ -2303,11 +2305,14 @@
(goto-char pos)))
;; (MARKER . OFFSET) means a marker MARKER was adjusted by OFFSET.
(`(,(and marker (pred markerp)) . ,(and offset (pred integerp)))
- (when (marker-buffer marker)
+ (when (and del-pos
+ (integerp (marker-position marker))
+ (= del-pos marker)
+ (marker-buffer marker))
(set-marker marker
(- marker offset)
(marker-buffer marker))))
- (_ (error "Unrecognized entry in undo list %S" next))))
+ (_ (error "Unrecognized entry in undo list %S" next)))))
(setq arg (1- arg)))
;; Make sure an apply entry produces at least one undo entry,
;; so the test in `undo' for continuing an undo series
The "move-after" markers will be at (+ del-pos (length inserted-text))
rather than at del-pos. Also, a lone (MARKER . OFFSET) entry will
arbitrarily use some unrelated earlier del-pos. Admittedly, such lone
(MARKER . OFFSET) entries should/will never happen, but I'd rather we
catch them and emit a warning than silently do something arbitrary.
IOW, I think we should only change the entry corresponding to a deletion
such that it directly handles all the immediately following
marker-adjustments (it can check them before doing the insertion, hence
using del-pos without having to care about insert-after vs
insert-before). Then the current handling of marker-adjustments can be
changed to emit a warning.
> @@ -2351,18 +2354,30 @@ If we find an element that crosses an edge of this region,
> we stop and ignore all further elements."
> (let ((undo-list-copy (undo-copy-list buffer-undo-list))
> (undo-list (list nil))
> - undo-adjusted-markers
> + ;; The position of a deletion record (TEXT . POSITION) of the
> + ;; current change group.
> + ;;
> + ;; This is used to check that marker adjustmenets are in the
> + ;; region. Bug 16818 describes why the marker's position is
> + ;; not suitable.
> + del-pos
> some-rejected
> undo-elt temp-undo-list delta)
> (while undo-list-copy
> (setq undo-elt (car undo-list-copy))
> + ;; Update del-pos
> + (if undo-elt
> + (when (and (consp undo-elt) (stringp (car undo-elt)))
> + (setq del-pos (cdr undo-elt)))
> + ;; Undo boundary means new change group, so unset del-pos
> + (setq del-pos nil))
> (let ((keep-this
> (cond ((and (consp undo-elt) (eq (car undo-elt) t))
> ;; This is a "was unmodified" element.
> ;; Keep it if we have kept everything thus far.
> (not some-rejected))
> (t
> - (undo-elt-in-region undo-elt start end)))))
> + (undo-elt-in-region undo-elt start end del-pos)))))
> (if keep-this
> (progn
> (setq end (+ end (cdr (undo-delta undo-elt))))
I'd have the same comment here, but if we emit a warning for sole
marker-adjustments in the "non-region" code, we don't really have to
worry about them here.
But this is also affected by the issue of "move-after" markers where
`del-pos' is not sufficient info since those markers won't be at del-pos
any more if they were at del-pos before we inserted the deleted text.
Stefan
next prev parent reply other threads:[~2014-03-18 0:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-19 22:15 bug#16818: Undo in region after markers in undo history relocated Barry OReilly
[not found] ` <handler.16818.B.13928481719895.ack@debbugs.gnu.org>
2014-02-19 23:07 ` bug#16818: Acknowledgement (Undo in region after markers in undo history relocated) Barry OReilly
2014-02-20 4:53 ` Stefan Monnier
2014-02-20 14:38 ` Barry OReilly
2014-02-24 22:46 ` Barry OReilly
2014-02-25 21:43 ` Stefan Monnier
2014-02-26 15:18 ` Barry OReilly
2014-03-11 21:24 ` Barry OReilly
2014-03-12 23:24 ` Stefan Monnier
2014-03-13 1:59 ` Barry OReilly
2014-03-13 13:24 ` Stefan Monnier
2014-03-13 14:35 ` Stefan Monnier
2014-03-13 16:55 ` Barry OReilly
2014-03-17 23:05 ` Barry OReilly
2014-03-18 0:02 ` Stefan [this message]
2014-03-19 13:36 ` Barry OReilly
2014-03-19 18:52 ` Stefan
2014-03-19 13:45 ` Barry OReilly
2014-03-19 18:56 ` Stefan
2014-03-23 22:49 ` Barry OReilly
2014-03-24 13:03 ` Stefan
2014-03-24 22:10 ` Barry OReilly
2014-03-25 1:28 ` Stefan
2014-03-25 2:32 ` Barry OReilly
2020-09-09 12:25 ` Lars Ingebrigtsen
2020-12-06 15:57 ` bug#16818: Undo in region after markers in undo history relocated Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwva9co2xs4.fsf-monnier+emacsbugs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=16818@debbugs.gnu.org \
--cc=gundaetiapo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.