GNU logs - #16411, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 10 Jan 2014 22:34:02 +0000
Resent-Message-ID: <handler.16411.B.13893932292240 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 16411 <at> debbugs.gnu.org
MIME-Version: 1.0
Date: Fri, 10 Jan 2014 17:33:37 -0500
Message-ID: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7b3a976034d74c04efa551a5
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--047d7b3a976034d74c04efa551a5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Looking over the code for the undo system, I found two bugs and
constructed recipes to demonstrate. For these, each "insert" should be
exactly one change group or the recipes may not work. I use Evil so
it's easy to arrange for that.

Recipe 1:
  =95 Insert "aaa"
  =95 Insert "bbb"
  =95 Undo
  =95 Insert "ccc"
  =95 Insert "ddd"
  =95 Undo
  =95 Undo-only with prefix arg 2
  =95 Expected: none of the above insertions are in the buffer
  =95 Actual: buffer has aaa and bbb insertions

Reason is that undo-only skips "redo records" prior to calling
undo-more through recursive lookup in undo-equiv-table. However, it
doesn't reference undo-equiv-table again as it iterates prefix-arg
times, so it may undo redo records after the first correct undo. In
this case, it redoes bbb.

I think the solution entails moving this sort of thing into a loop in
undo-more:

  (when (and (consp equiv) undo-no-redo)
    ;; The equiv entry might point to another redo record if we have done
    ;; undo-redo-undo-redo-... so skip to the very last equiv.
    (while (let ((next (gethash equiv undo-equiv-table)))
             (if next (setq equiv next))))
    (setq pending-undo-list equiv))

Recipe 2:
  =95 Insert "aaa"
  =95 Insert "bbb"
  =95 Mark region around "aaa" but not "bbb"
  =95 Undo (in region)
  =95 Mark region around "bbb" and where "aaa" used to be
  =95 Undo-only
  =95 Expected: none of the above insertions are in the buffer
  =95 Actual: buffer has aaa and bbb insertions

The code appears to simply punt on undo-only in region and behaves
like ordinary undo. Thus it undoes the redo record to bring back bbb.

One idea I have to solve bug 2 is to extend undo-equiv-table or create
another redo-record-table weak hash table with the same key type as
the undo-equiv-table: a "redo record" as a cons of buffer-undo-list.
The value would have prefix-arg number of "undone records" which that
redo record undid.

When undo-only in region using the redo-record-table the algorithm
would go roughly like:

  While pending-undo-list non nil:
    Pop undo-i from pending-undo-list:
    If undo-i is a redo record (exists in the table):
      Remove undo-i's undone records from pending-undo-list (or
      otherwise arrange to skip it)
    Else:
      Undo undo-i
      If "undo undo-i" was done prefix-arg times:
        Break (finished)
  Reached end of undo history

As a non rigorous example, if there is an undo A of an undo B of an
edit C in the region:
  =95 When undo-i is A, B is removed from consideration
  =95 With B gone, undo-i never becomes B, so C remains in
    pending-undo-list. A and B effectively cancelled each other out
  =95 C is correctly picked for the undo-only

The reason undo-equiv-table is insufficient is because its value is
the change group *after* the undone record. That change group may have
been filtered out of pending-undo-list. OTOH, replacing existing usage
of undo-equiv-table with the proposed redo-record-table is straight
forward: go one change group forward to get the same value as the
undo-equiv-table. Thus undo-equiv-table could be phased out in favor
of using the redo-record-table.

Another issue is that for both recipes, Emacs echos "Undo!". For bug
2, it does not match what Emacs actually did. For bug 1, it is partly
incorrect because Emacs did an undo and a redo. Perhaps when (< 1
prefix-arg), the echo message should convey more. Possible messages
might be "Undo, redo!" and "Redo, undo, undo! No further undo
information"

The reason I'm looking at this code at all is that I am investigating
Stefan's guidance [1] about better integrating undo-tree with the
builtin undo system. I think redo-record-table may help to this end,
but I'll elaborate on that at later time. No later than the time I
would submit a patch for bug 2, if welcome.

[1]
http://lists.gnu.org/archive/html/gnu-emacs-sources/2009-11/msg00010.html

--047d7b3a976034d74c04efa551a5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Looking over the code for the undo system, I found tw=
o bugs and<br>constructed recipes to demonstrate. For these, each &quot;ins=
ert&quot; should be<br>exactly one change group or the recipes may not work=
. I use Evil so<br>
it&#39;s easy to arrange for that.<br><br>Recipe 1:<br>=A0 =95 Insert &quot=
;aaa&quot;<br>=A0 =95 Insert &quot;bbb&quot;<br>=A0 =95 Undo<br>=A0 =95 Ins=
ert &quot;ccc&quot;<br>=A0 =95 Insert &quot;ddd&quot;<br>=A0 =95 Undo<br>=
=A0 =95 Undo-only with prefix arg 2<br>
=A0 =95 Expected: none of the above insertions are in the buffer<br>=A0 =95=
 Actual: buffer has aaa and bbb insertions<br><br>Reason is that undo-only =
skips &quot;redo records&quot; prior to calling<br>undo-more through recurs=
ive lookup in undo-equiv-table. However, it<br>
doesn&#39;t reference undo-equiv-table again as it iterates prefix-arg<br>t=
imes, so it may undo redo records after the first correct undo. In<br>this =
case, it redoes bbb.<br><br>I think the solution entails moving this sort o=
f thing into a loop in<br>
undo-more:<br><br>=A0 (when (and (consp equiv) undo-no-redo)<br>=A0=A0=A0 ;=
; The equiv entry might point to another redo record if we have done<br>=A0=
=A0=A0 ;; undo-redo-undo-redo-... so skip to the very last equiv.<br>=A0=A0=
=A0 (while (let ((next (gethash equiv undo-equiv-table)))<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (if next (setq equiv next))))<br>=A0=
=A0=A0 (setq pending-undo-list equiv))<br><br>Recipe 2:<br>=A0 =95 Insert &=
quot;aaa&quot;<br>=A0 =95 Insert &quot;bbb&quot;<br>=A0 =95 Mark region aro=
und &quot;aaa&quot; but not &quot;bbb&quot;<br>
=A0 =95 Undo (in region)<br>=A0 =95 Mark region around &quot;bbb&quot; and =
where &quot;aaa&quot; used to be<br>=A0 =95 Undo-only<br>=A0 =95 Expected: =
none of the above insertions are in the buffer<br>=A0 =95 Actual: buffer ha=
s aaa and bbb insertions<br>
<br>The code appears to simply punt on undo-only in region and behaves<br>l=
ike ordinary undo. Thus it undoes the redo record to bring back bbb.<br><br=
>One idea I have to solve bug 2 is to extend undo-equiv-table or create<br>
another redo-record-table weak hash table with the same key type as<br>the =
undo-equiv-table: a &quot;redo record&quot; as a cons of buffer-undo-list.<=
br>The value would have prefix-arg number of &quot;undone records&quot; whi=
ch that<br>
redo record undid.<br><br>When undo-only in region using the redo-record-ta=
ble the algorithm<br>would go roughly like:<br><br>=A0 While pending-undo-l=
ist non nil:<br>=A0=A0=A0 Pop undo-i from pending-undo-list:<br>=A0=A0=A0 I=
f undo-i is a redo record (exists in the table):<br>
=A0=A0=A0=A0=A0 Remove undo-i&#39;s undone records from pending-undo-list (=
or<br>=A0=A0=A0=A0=A0 otherwise arrange to skip it)<br>=A0=A0=A0 Else:<br>=
=A0=A0=A0=A0=A0 Undo undo-i<br>=A0=A0=A0=A0=A0 If &quot;undo undo-i&quot; w=
as done prefix-arg times:<br>=A0=A0=A0=A0=A0=A0=A0 Break (finished)<br>
=A0 Reached end of undo history<br><br>As a non rigorous example, if there =
is an undo A of an undo B of an<br>edit C in the region:<br>=A0 =95 When un=
do-i is A, B is removed from consideration<br>=A0 =95 With B gone, undo-i n=
ever becomes B, so C remains in<br>
=A0=A0=A0 pending-undo-list. A and B effectively cancelled each other out<b=
r>=A0 =95 C is correctly picked for the undo-only<br></div><div><br>The rea=
son undo-equiv-table is insufficient is because its value is<br>the change =
group *after* the undone record. That change group may have<br>
been filtered out of pending-undo-list. OTOH, replacing existing usage<br>o=
f undo-equiv-table with the proposed redo-record-table is straight<br>forwa=
rd: go one change group forward to get the same value as the<br>undo-equiv-=
table. Thus undo-equiv-table could be phased out in favor<br>
of using the redo-record-table.<br><br>Another issue is that for both recip=
es, Emacs echos &quot;Undo!&quot;. For bug<br>2, it does not match what Ema=
cs actually did. For bug 1, it is partly<br>incorrect because Emacs did an =
undo and a redo. Perhaps when (&lt; 1<br>
prefix-arg), the echo message should convey more. Possible messages<br>migh=
t be &quot;Undo, redo!&quot; and &quot;Redo, undo, undo! No further undo<br=
>information&quot;<br><br>The reason I&#39;m looking at this code at all is=
 that I am investigating<br>
Stefan&#39;s guidance [1] about better integrating undo-tree with the<br>bu=
iltin undo system. I think redo-record-table may help to this end,<br>but I=
&#39;ll elaborate on that at later time. No later than the time I<br>would =
submit a patch for bug 2, if welcome.<br>
<br>[1] <a href=3D"http://lists.gnu.org/archive/html/gnu-emacs-sources/2009=
-11/msg00010.html">http://lists.gnu.org/archive/html/gnu-emacs-sources/2009=
-11/msg00010.html</a><br><br></div></div>

--047d7b3a976034d74c04efa551a5--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: bug#16411: Acknowledgement (undo-only bugs)
Message-ID: <handler.16411.B.13893932292240.ack <at> debbugs.gnu.org>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
X-Gnu-PR-Message: ack 16411
X-Gnu-PR-Package: emacs
Reply-To: 16411 <at> debbugs.gnu.org
Date: Fri, 10 Jan 2014 22:34:03 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 16411 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
16411: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D16411
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 10 Jan 2014 23:56:02 +0000
Resent-Message-ID: <handler.16411.B16411.138939810410602 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
Date: Fri, 10 Jan 2014 18:54:57 -0500
In-Reply-To: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 (Barry OReilly's message of "Fri, 10 Jan 2014 17:33:37 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> I think the solution entails moving this sort of thing into a loop in
> undo-more:

>   (when (and (consp equiv) undo-no-redo)
>     ;; The equiv entry might point to another redo record if we have done
>     ;; undo-redo-undo-redo-... so skip to the very last equiv.
>     (while (let ((next (gethash equiv undo-equiv-table)))
>              (if next (setq equiv next))))
>     (setq pending-undo-list equiv))

Indeed.  Or, equivalently, changing `undo' so it only calls undo-more with
argument 1 (and use the above while loop between each call to undo-more).

> Recipe 2:
>   =E2=80=A2 Insert "aaa"
>   =E2=80=A2 Insert "bbb"
>   =E2=80=A2 Mark region around "aaa" but not "bbb"
>   =E2=80=A2 Undo (in region)
>   =E2=80=A2 Mark region around "bbb" and where "aaa" used to be
>   =E2=80=A2 Undo-only
>   =E2=80=A2 Expected: none of the above insertions are in the buffer
>   =E2=80=A2 Actual: buffer has aaa and bbb insertions

> The code appears to simply punt on undo-only in region and behaves
> like ordinary undo. Thus it undoes the redo record to bring back bbb.

undo-in-region does not implement undo-only, indeed.  I think the way to
implement undo-only is to change undo-make-selective-list so it also
skips redo entries (depending on undo-no-redo, obviously) using the
above while loop.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 11 Jan 2014 03:49:01 +0000
Resent-Message-ID: <handler.16411.B16411.13894121203871 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
MIME-Version: 1.0
In-Reply-To: <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
Date: Fri, 10 Jan 2014 22:48:34 -0500
Message-ID: <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7b33d5a08efd3f04efa9b7de
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

 Content preview:  > undo-in-region does not implement undo-only, indeed. I think
    the way > to implement undo-only is to change undo-make-selective-list so
    it > also skips redo entries (depending on undo-no-redo, obviously) using
    > the above while loop. [...] 

 Content analysis details:   (2.9 points, 10.0 required)

  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [209.85.219.46 listed in list.dnswl.org]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (gundaetiapo[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 TVD_PH_REC             BODY: Message includes a phrase commonly used in phishing
                             mails
  0.0 HTML_MESSAGE           BODY: HTML included in message
  1.5 TVD_PH_BODY_ACCOUNTS_PRE The body matches phrases such as "accounts
                             suspended", "account credited", "account
                             verification"
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

--047d7b33d5a08efd3f04efa9b7de
Content-Type: text/plain; charset=ISO-8859-1

> undo-in-region does not implement undo-only, indeed. I think the way
> to implement undo-only is to change undo-make-selective-list so it
> also skips redo entries (depending on undo-no-redo, obviously) using
> the above while loop.

I don't see how that's a correct solution in the face of arbitrary
regional undos and prefix args. Would you have the redo records
resulting from regional undos still map to t in the undo-equiv-table?
How does your solution account for redo records that undid several
because of prefix-arg? undo-equiv-table only maps to the change group
after the last undone record without information about the (1-
prefix-arg) others.

My proposition accounts for these considerations and I think is
correct. If not I hope to find out when I start hacking it.

--047d7b33d5a08efd3f04efa9b7de
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">&gt; undo-in-region does not implement undo-only, indeed. I think the way<br>&gt; to implement undo-only is to change undo-make-selective-list so it<br>&gt; also skips redo entries (depending on undo-no-redo, obviously) using<br>
&gt; the above while loop.<br><br>I don&#39;t see how that&#39;s a correct solution in the face of arbitrary<br>regional undos and prefix args. Would you have the redo records<br>resulting from regional undos still map to t in the undo-equiv-table?<br>
How does your solution account for redo records that undid several<br>because of prefix-arg? undo-equiv-table only maps to the change group<br>after the last undone record without information about the (1-<br>prefix-arg) others.<br>
<br>My proposition accounts for these considerations and I think is<br>correct. If not I hope to find out when I start hacking it.<br><br></div>

--047d7b33d5a08efd3f04efa9b7de--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 11 Jan 2014 04:30:03 +0000
Resent-Message-ID: <handler.16411.B16411.13894145588412 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.13894145588412
          (code B ref 16411); Sat, 11 Jan 2014 04:30:03 +0000
Received: (at 16411) by debbugs.gnu.org; 11 Jan 2014 04:29:18 +0000
Received: from localhost ([127.0.0.1]:45920 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W1qCE-0002Bc-2N
	for submit <at> debbugs.gnu.org; Fri, 10 Jan 2014 23:29:18 -0500
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:48528)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1W1qCB-0002BR-U1
 for 16411 <at> debbugs.gnu.org; Fri, 10 Jan 2014 23:29:16 -0500
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxKG9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLLQcSFBgNJC6HcAbBLY1VgzUDiGGcGYFegxWBUYEy
X-IPAS-Result: Av4EABK/CFFFxKG9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLLQcSFBgNJC6HcAbBLY1VgzUDiGGcGYFegxWBUYEy
X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44708489"
Received: from 69-196-161-189.dsl.teksavvy.com (HELO pastel.home)
 ([69.196.161.189])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 10 Jan 2014 23:29:14 -0500
Received: by pastel.home (Postfix, from userid 20848)
 id 540306045A; Fri, 10 Jan 2014 23:29:14 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
Date: Fri, 10 Jan 2014 23:29:14 -0500
In-Reply-To: <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
 (Barry OReilly's message of "Fri, 10 Jan 2014 22:48:34 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 3.8 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  >> undo-in-region does not implement undo-only, indeed. I
 think the way >> to implement undo-only is to change undo-make-selective-list
 so it >> also skips redo entries (depending on undo-no-redo, obviously) using
 >> the above while loop. > I don't see how that's a correct solution in the
 face of arbitrary > regional undos and prefix args. Would you have the redo
 records > resulting from regional undos still map to t in the
 undo-equiv-table? [...] 
 Content analysis details:   (3.8 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [206.248.154.181 listed in list.dnswl.org]
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 2.0 TVD_PH_REC BODY: Message includes a phrase commonly used in phishing
 mails
 1.5 TVD_PH_BODY_ACCOUNTS_PRE The body matches phrases such as "accounts
 suspended", "account credited", "account verification"
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 3.8 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  >> undo-in-region does not implement undo-only, indeed. I
   think the way >> to implement undo-only is to change undo-make-selective-list
    so it >> also skips redo entries (depending on undo-no-redo, obviously) using
    >> the above while loop. > I don't see how that's a correct solution in the
    face of arbitrary > regional undos and prefix args. Would you have the redo
    records > resulting from regional undos still map to t in the undo-equiv-table?
    [...] 
 
 Content analysis details:   (3.8 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [206.248.154.181 listed in list.dnswl.org]
  1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
  2.0 TVD_PH_REC             BODY: Message includes a phrase commonly used in phishing
                             mails
  1.5 TVD_PH_BODY_ACCOUNTS_PRE The body matches phrases such as "accounts
                             suspended", "account credited", "account
                             verification"

>> undo-in-region does not implement undo-only, indeed.  I think the way
>> to implement undo-only is to change undo-make-selective-list so it
>> also skips redo entries (depending on undo-no-redo, obviously) using
>> the above while loop.
> I don't see how that's a correct solution in the face of arbitrary
> regional undos and prefix args. Would you have the redo records
> resulting from regional undos still map to t in the undo-equiv-table?

I was talking about simply making undo-in-region
properly skip the previous undos (presuming they don't themselves come
from an undo-in-region).

IIUC, you're talking of skipping (e.g. in a non-region undo) the undos
that took place during undo-in-region, right?  If so, I don't have an
answer for how we could do that, in general.

In your pseudo-code:

  While pending-undo-list non nil:
    Pop undo-i from pending-undo-list:
    If undo-i is a redo record (exists in the table):
      Remove undo-i's undone records from pending-undo-list (or
      otherwise arrange to skip it)
    Else:
      Undo undo-i
      If "undo undo-i" was done prefix-arg times:
        Break (finished)
  Reached end of undo history

I have no idea how to implement the part:

      Remove undo-i's undone records from pending-undo-list (or
      otherwise arrange to skip it)

I guess I do have some idea how to do it, but it looks like a lot of
work, since we have to adjust the positions in the rest of
pending-undo-list.

Other than that I don't understand what your redo-record-table does.
AFAICT the test "undo-i is a redo record" can be performed with
undo-equiv-table.

> How does your solution account for redo records that undid several
> because of prefix-arg?

As you have discovered the current code does not even try to account for
prefix args.

> undo-equiv-table only maps to the change group
> after the last undone record without information about the (1-
> prefix-arg) others.

Right: the loop that undoes N steps (either in undo-more or in undo if
we change undo to only call undo-more with a 1) needs not only to use
undo-equiv-table at each iteration to skip redo entries, but it also
needs to add an entry in undo-equiv-table at each iteration.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 11 Jan 2014 05:10:02 +0000
Resent-Message-ID: <handler.16411.B16411.138941696913020 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.138941696913020
          (code B ref 16411); Sat, 11 Jan 2014 05:10:02 +0000
Received: (at 16411) by debbugs.gnu.org; 11 Jan 2014 05:09:29 +0000
Received: from localhost ([127.0.0.1]:45956 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W1qp6-0003Nw-JK
	for submit <at> debbugs.gnu.org; Sat, 11 Jan 2014 00:09:28 -0500
Received: from mail-oa0-f49.google.com ([209.85.219.49]:42602)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1W1qp4-0003Nk-Pg
 for 16411 <at> debbugs.gnu.org; Sat, 11 Jan 2014 00:09:27 -0500
Received: by mail-oa0-f49.google.com with SMTP id n16so5941081oag.36
 for <16411 <at> debbugs.gnu.org>; Fri, 10 Jan 2014 21:09:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=cTIvjE9YkYRYV1Qzc4TJ4lYfv23Wezzzx+7eJSKRuqk=;
 b=cZrxCIJTtedcazkDVpcoNTWtVosP8fz/lrn0gE8CjhX2dfARtHrt899dlmh+EXEFnN
 KjyttK4puA5OAIXT78Gnv+Hm6zas03Boz1XVwmvRdzQbjlfHD5DUv3HW2NTprkOlHNLl
 qUnKnvhwvRaGvK3wj9lPiRoqB+0u1nOY4wCiWMYaCx5rPHDSlS9KDgRFW9xsFhytEyDF
 0zTUZOjnt/PdxHWgaia7NCSBLzJ5DPBzPoS0tFexp4A+EuCjDIS5ud+PpmaqpZ+P6wYx
 29TfajoE28101MbU6KXDLG1ovnSn9Qff/xmd9HGmjKMFLLAm6+sXH7hf2+J1D4pNzVAm
 9NWA==
MIME-Version: 1.0
X-Received: by 10.60.44.179 with SMTP id f19mr11312635oem.43.1389416966086;
 Fri, 10 Jan 2014 21:09:26 -0800 (PST)
Received: by 10.76.114.74 with HTTP; Fri, 10 Jan 2014 21:09:26 -0800 (PST)
In-Reply-To: <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
 <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
Date: Sat, 11 Jan 2014 00:09:26 -0500
Message-ID: <CAFM41H3Li=sKXQ6pjdyk5E+rivUeOq5TF3aJ624Cdr=2ppMBtg@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=001a1133407eb566cf04efaad85a
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a1133407eb566cf04efaad85a
Content-Type: text/plain; charset=ISO-8859-1

> I guess I do have some idea how to do it, but it looks like a lot of
> work, since we have to adjust the positions in the rest of
> pending-undo-list.

Are you saying the buffer positions in the undo data become
invalidated? That could indeed be a detail I missed. Let me take a
closer look.

> Right: the loop that undoes N steps (either in undo-more or in undo
> if we change undo to only call undo-more with a 1) needs not only to
> use undo-equiv-table at each iteration to skip redo entries, but it
> also needs to add an entry in undo-equiv-table at each iteration.

And recall that these N are rolled into one redo record. So a redo
record needs to reference N records it undid. That means
undo-equiv-table's value type has a new format that could conceivably
break user code, so let's name it something different:
redo-record-table. Now the only difference with redo-record-table as I
described it earlier is the off-by-one-change-group difference.

Actually, this makes me realize the solution to bug 1 is inadequate.
Calling (undo-primitive 1) N times creates N redo records whereas
(undo-primitive N) creates one.

--001a1133407eb566cf04efaad85a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; I guess I do have some idea how to do it, but it look=
s like a lot of<br>&gt; work, since we have to adjust the positions in the =
rest of<br>&gt; pending-undo-list.<br><br>Are you saying the buffer positio=
ns in the undo data become<br>
invalidated? That could indeed be a detail I missed. Let me take a<br>close=
r look.<br><br>&gt; Right: the loop that undoes N steps (either in undo-mor=
e or in undo<br>&gt; if we change undo to only call undo-more with a 1) nee=
ds not only to<br>
&gt; use undo-equiv-table at each iteration to skip redo entries, but it<br=
>&gt; also needs to add an entry in undo-equiv-table at each iteration.<br>=
<br>And recall that these N are rolled into one redo record. So a redo<br>
record needs to reference N records it undid. That means<br>undo-equiv-tabl=
e&#39;s value type has a new format that could conceivably<br>break user co=
de, so let&#39;s name it something different:<br>redo-record-table. Now the=
 only difference with redo-record-table as I<br>
described it earlier is the off-by-one-change-group difference.<br><br>Actu=
ally, this makes me realize the solution to bug 1 is inadequate.<br>Calling=
 (undo-primitive 1) N times creates N redo records whereas<br>(undo-primiti=
ve N) creates one.<br>
<br></div>

--001a1133407eb566cf04efaad85a--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Jan 2014 00:50:01 +0000
Resent-Message-ID: <handler.16411.B16411.138966058430461 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.138966058430461
          (code B ref 16411); Tue, 14 Jan 2014 00:50:01 +0000
Received: (at 16411) by debbugs.gnu.org; 14 Jan 2014 00:49:44 +0000
Received: from localhost ([127.0.0.1]:49535 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W2sCN-0007vE-H8
	for submit <at> debbugs.gnu.org; Mon, 13 Jan 2014 19:49:43 -0500
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:40599)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1W2sCL-0007v3-4C
 for 16411 <at> debbugs.gnu.org; Mon, 13 Jan 2014 19:49:41 -0500
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCoyj/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kLodwBsEtkQoDiGGcGYFegxU
X-IPAS-Result: Av4EABK/CFFMCoyj/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kLodwBsEtkQoDiGGcGYFegxU
X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44868956"
Received: from 76-10-140-163.dsl.teksavvy.com (HELO pastel.home)
 ([76.10.140.163])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 13 Jan 2014 19:49:40 -0500
Received: by pastel.home (Postfix, from userid 20848)
 id F3DDE6105F; Mon, 13 Jan 2014 19:49:39 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvmwizqttu.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
 <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Li=sKXQ6pjdyk5E+rivUeOq5TF3aJ624Cdr=2ppMBtg@HIDDEN>
Date: Mon, 13 Jan 2014 19:49:39 -0500
In-Reply-To: <CAFM41H3Li=sKXQ6pjdyk5E+rivUeOq5TF3aJ624Cdr=2ppMBtg@HIDDEN>
 (Barry OReilly's message of "Sat, 11 Jan 2014 00:09:26 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

>> I guess I do have some idea how to do it, but it looks like a lot of
>> work, since we have to adjust the positions in the rest of
>> pending-undo-list.
> Are you saying the buffer positions in the undo data become
> invalidated?  That could indeed be a detail I missed.  Let me take a
> closer look.

Not exactly invalidated, but we can't just skip an undo-record without
adjusting the subsequent records.

We can skip a bunch of undo-record specified via undo-equiv-table
because that table stores pairs of undo states that correspond
to the exact same buffer, so the "adjustment" is a no-op.

>> Right: the loop that undoes N steps (either in undo-more or in undo
>> if we change undo to only call undo-more with a 1) needs not only to
>> use undo-equiv-table at each iteration to skip redo entries, but it
>> also needs to add an entry in undo-equiv-table at each iteration.
> And recall that these N are rolled into one redo record.

Not sure what you mean here.

> So a redo record needs to reference N records it undid.

I'm even more confused.

> Actually, this makes me realize the solution to bug 1 is inadequate.
> Calling (undo-primitive 1) N times creates N redo records whereas
> (undo-primitive N) creates one.

No, primitive-undo does not add any undo boundary.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Jan 2014 01:53:02 +0000
Resent-Message-ID: <handler.16411.B16411.13896643275467 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.13896643275467
          (code B ref 16411); Tue, 14 Jan 2014 01:53:02 +0000
Received: (at 16411) by debbugs.gnu.org; 14 Jan 2014 01:52:07 +0000
Received: from localhost ([127.0.0.1]:49574 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W2tAl-0001Q6-9y
	for submit <at> debbugs.gnu.org; Mon, 13 Jan 2014 20:52:07 -0500
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58710)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1W2tAj-0001Pw-UO
 for 16411 <at> debbugs.gnu.org; Mon, 13 Jan 2014 20:52:06 -0500
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCoyj/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSQuh3AGwS2RCgOIYZwZgV6DFQ
X-IPAS-Result: Av4EABK/CFFMCoyj/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSQuh3AGwS2RCgOIYZwZgV6DFQ
X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44871627"
Received: from 76-10-140-163.dsl.teksavvy.com (HELO pastel.home)
 ([76.10.140.163])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 13 Jan 2014 20:52:04 -0500
Received: by pastel.home (Postfix, from userid 20848)
 id A6350612B0; Mon, 13 Jan 2014 20:52:04 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvob3fpc3n.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
 <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Li=sKXQ6pjdyk5E+rivUeOq5TF3aJ624Cdr=2ppMBtg@HIDDEN>
 <jwvmwizqttu.fsf-monnier+emacsbugs@HIDDEN>
Date: Mon, 13 Jan 2014 20:52:04 -0500
In-Reply-To: <jwvmwizqttu.fsf-monnier+emacsbugs@HIDDEN> (Stefan Monnier's
 message of "Mon, 13 Jan 2014 19:49:39 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

>> Actually, this makes me realize the solution to bug 1 is inadequate.
>> Calling (undo-primitive 1) N times creates N redo records whereas
>> (undo-primitive N) creates one.
> No, primitive-undo does not add any undo boundary.

Actually, now I'm not sure what you meant by "redo records".
(primitive-undo N) will undo all the M "records" that appear before the
next Nth undo boundary, and will correspondingly add M redo "records",
but no boundary.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Jan 2014 14:01:02 +0000
Resent-Message-ID: <handler.16411.B16411.138970802127167 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.138970802127167
          (code B ref 16411); Tue, 14 Jan 2014 14:01:02 +0000
Received: (at 16411) by debbugs.gnu.org; 14 Jan 2014 14:00:21 +0000
Received: from localhost ([127.0.0.1]:49842 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W34XT-000746-NU
	for submit <at> debbugs.gnu.org; Tue, 14 Jan 2014 09:00:20 -0500
Received: from mail-oa0-f52.google.com ([209.85.219.52]:64708)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1W34XP-00073u-Mm
 for 16411 <at> debbugs.gnu.org; Tue, 14 Jan 2014 09:00:16 -0500
Received: by mail-oa0-f52.google.com with SMTP id o6so9702077oag.11
 for <16411 <at> debbugs.gnu.org>; Tue, 14 Jan 2014 06:00:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=76UgH3ApwTwV7EAlonz9cUCD6YWP0WOVsM6+QHKWxEQ=;
 b=olxa8wyaAgqNH6rXBNOFuLRg/gst7U+LN1lC25I8XD8HcweVfQcRZ+yXXpSeRtK1XA
 YaTS+7Ygd1N/iou3njNRJzdydTDVYV0xHHCpRPtWrrtMODVfbWkYwLelMybx87+byZDd
 V2MdK9XUEvHbqvRXmr2pY3eHQwjXZ6w6kWV5iI1J9Fqgm1MbpQ4ENR1TKTi3Ggu70nrO
 VZp9naBJfBYCG1Oh8XiCjPTJtI2+EZny1rhRodeH5DC7KiU7MYiwHoq2m+KLE70MYY4C
 gKC58yBI5C63Te5dxYWws08ddIOmv8ZnNggskNMASMQzqFAfR8GosfQ+uzypDBMxyuUe
 LjXQ==
MIME-Version: 1.0
X-Received: by 10.60.52.83 with SMTP id r19mr1181747oeo.1.1389708014787; Tue,
 14 Jan 2014 06:00:14 -0800 (PST)
Received: by 10.76.21.84 with HTTP; Tue, 14 Jan 2014 06:00:14 -0800 (PST)
In-Reply-To: <jwvob3fpc3n.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
 <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Li=sKXQ6pjdyk5E+rivUeOq5TF3aJ624Cdr=2ppMBtg@HIDDEN>
 <jwvmwizqttu.fsf-monnier+emacsbugs@HIDDEN>
 <jwvob3fpc3n.fsf-monnier+emacsbugs@HIDDEN>
Date: Tue, 14 Jan 2014 09:00:14 -0500
Message-ID: <CAFM41H3Q2je+rOUordHv5WbLmWqKPmXFdm_LdBnmGCZ48wA5AQ@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11330904901e7504efee9c9e
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11330904901e7504efee9c9e
Content-Type: text/plain; charset=ISO-8859-1

> >> Actually, this makes me realize the solution to bug 1 is
> >> inadequate. Calling (undo-primitive 1) N times creates N redo
> >> records whereas (undo-primitive N) creates one.
> > No, primitive-undo does not add any undo boundary.

> Actually, now I'm not sure what you meant by "redo records".
> (primitive-undo N) will undo all the M "records" that appear before
> the next Nth undo boundary, and will correspondingly add M redo
> "records", but no boundary.

I took another look at the code and see I was mistaken on this point.
I'll work on a patch.

--001a11330904901e7504efee9c9e
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">&gt; &gt;&gt; Actually, this makes me realize the solution to bug 1 is<br>&gt; &gt;&gt; inadequate. Calling (undo-primitive 1) N times creates N redo<br>&gt; &gt;&gt; records whereas (undo-primitive N) creates one.<br>
&gt; &gt; No, primitive-undo does not add any undo boundary.<br><br>&gt; Actually, now I&#39;m not sure what you meant by &quot;redo records&quot;.<br>&gt; (primitive-undo N) will undo all the M &quot;records&quot; that appear before<br>
&gt; the next Nth undo boundary, and will correspondingly add M redo<br>&gt; &quot;records&quot;, but no boundary.<br><br>I took another look at the code and see I was mistaken on this point.<br>I&#39;ll work on a patch.<br>
<br></div>

--001a11330904901e7504efee9c9e--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 Jan 2014 00:59:02 +0000
Resent-Message-ID: <handler.16411.B16411.13900931016874 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.13900931016874
          (code B ref 16411); Sun, 19 Jan 2014 00:59:02 +0000
Received: (at 16411) by debbugs.gnu.org; 19 Jan 2014 00:58:21 +0000
Received: from localhost ([127.0.0.1]:56473 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W4giS-0001mk-28
	for submit <at> debbugs.gnu.org; Sat, 18 Jan 2014 19:58:21 -0500
Received: from mail-ob0-f171.google.com ([209.85.214.171]:36412)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1W4giN-0001mX-V1
 for 16411 <at> debbugs.gnu.org; Sat, 18 Jan 2014 19:58:16 -0500
Received: by mail-ob0-f171.google.com with SMTP id wp4so713354obc.16
 for <16411 <at> debbugs.gnu.org>; Sat, 18 Jan 2014 16:58:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=5BBlDdTUOBQirAZP2vJbPDTZpk5kPb6gYHkUdZIRQ+Q=;
 b=MZqTRvqKTQ36sZMpcEVzohl4MBKteMTazE0HNrpE7CbEZLU/Tg77i3YNE49Ew7HIZW
 FE1y+KG35rP+mPU6tTxePZVI2SsOBskUi1mr/iqcy5zYzPhjlJrEcYWuZDrQKQtadko3
 QyvnS72UyGc8j+XeocSuf39+Ym2xITlgfdF+2yfJKx+eKjU2U2zZ8hM7WB9LnXDh1RzK
 4bc7yW+bvC0ZbLEgtg+wY9Wc6ABA509XtoSC5s1GOrR7s7QtQKWKl2N4+wou0NB3EJgt
 lXfhIe4eB8wjSYH2lgcEvCgyhAgmXhmuW1CpdK9xbtpRgMuqqmjuvQrzrSq2mHCnj68u
 TGSg==
MIME-Version: 1.0
X-Received: by 10.60.98.174 with SMTP id ej14mr8752651oeb.16.1390093094855;
 Sat, 18 Jan 2014 16:58:14 -0800 (PST)
Received: by 10.76.21.84 with HTTP; Sat, 18 Jan 2014 16:58:14 -0800 (PST)
In-Reply-To: <CAFM41H3Q2je+rOUordHv5WbLmWqKPmXFdm_LdBnmGCZ48wA5AQ@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
 <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Li=sKXQ6pjdyk5E+rivUeOq5TF3aJ624Cdr=2ppMBtg@HIDDEN>
 <jwvmwizqttu.fsf-monnier+emacsbugs@HIDDEN>
 <jwvob3fpc3n.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Q2je+rOUordHv5WbLmWqKPmXFdm_LdBnmGCZ48wA5AQ@HIDDEN>
Date: Sat, 18 Jan 2014 19:58:14 -0500
Message-ID: <CAFM41H1-Ud8Kaw0hdShe8HgNUhfkKoyLG8_cxyUj0FeDB3TyRg@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=089e0122912c1fa7a504f04845c5
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e0122912c1fa7a504f04845c5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

After looking at and considering more of the undo code, here's my
current thinking about how to solve bug 2.

The Elisp manual states that undo elements of buffer-undo-list can be
of the form:

  (apply delta beg end funname . args)

Define a "redo element" as an element of buffer-undo-list created
because of an undo command. Suppose we change the way redo elements
are represented to:

  (apply delta beg end 'undo-redo . (undone-element undo-delta))

Where:
  =95 delta, beg, end are as documented.
  =95 undo-redo is a new function that copies undone-element, applies
    undo-delta, then calls primitive-undo on it.
  =95 undone-element is the undone element of buffer-undo-list.
  =95 undo-delta is (position . offset) indicating how undo-redo should
    modify a copy of undone-element in order to carry out the redo.

When executing undo-only:
  =95 Assume pending-undo-list can be lazily computed
  =95 Let undo-skip-set be an empty set of undo elements to skip
  =95 Iterate over pending-undo-list until prefix-arg undos complete:
    =95 If the element is in undo-skip-set:
      =95 Remove it from undo-skip-set
      =95 Continue loop
    =95 If the element is of the form for a redo element:
      =95 Insert its undone-element in the undo-skip-set
    =95 Else undo the element

Using a BST for the undo-skip-set would be appropriate, but I don't
see that one is available to core Elisp code. A skip list data
structure would be a simple option with similar performance
characteristics. Note: this is a different kind of "skip", you can
duckduckgo "skip lists".

In your earlier reply, you hinted that switching undo-only from using
the undo-equiv-table to calling undo-make-selective-list might create
a noticable performance regression. The latter is O(N*N) for N sized
undo history! I would expect undo-only will generally have an element
to find, in which case, being able to compute next elements of
pending-undo-list as needed instead of in full upfront may be a
sufficient solution.

If it isn't sufficient, I can also make the algorithm O(N*log(N)).
One way to do this is using another skip list to store the
undo-deltas: sort by position, and at each node store the sum of the
offsets over the skip interval following that node. The analogous
thing can be done with a BST: put the sum of a subtree's offsets at
each node. This is more complex in part because the sums need to be
updated during tree rotations.

There's another benefit to my proposed representation for redo
elements. Consider the use case:
  =95 Delete text X bytes large
  =95 Do Y cycles of undo and redo

As I understand the current code, the size of undo history grows by
approximately X*Y. With this new way to represent redo elements, undo
history grows approximately Y instead.

This proposal implies recursive calls to primitive-undo. The size of
the Lisp call stack would be a function of how deep redo records refer
to undone redo records. Maybe there are reasonable ways to deal with
that or maybe it's a non issue.

Are there examples of existing code putting (apply delta beg end
funname . args) into the buffer-undo-list? I want to see what the
options might be for pushing redo elements in that format. The best I
can think of right now is a dynamically bound variable set only during
an undo and examined in record functions in undo.c.

There's more I could say about other details, but I'll stop now to get
feedback on the overall idea.

--089e0122912c1fa7a504f04845c5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">After looking at and considering more of the undo code, he=
re&#39;s my<br>current thinking about how to solve bug 2.<br><br>The Elisp =
manual states that undo elements of buffer-undo-list can be<br>of the form:=
<br>
<br>=A0 (apply delta beg end funname . args)<br><br>Define a &quot;redo ele=
ment&quot; as an element of buffer-undo-list created<br>because of an undo =
command. Suppose we change the way redo elements<br>are represented to:<br>
<br>=A0 (apply delta beg end &#39;undo-redo . (undone-element undo-delta))<=
br><br>Where:<br>=A0 =95 delta, beg, end are as documented.<br>=A0 =95 undo=
-redo is a new function that copies undone-element, applies<br>=A0=A0=A0 un=
do-delta, then calls primitive-undo on it.<br>
=A0 =95 undone-element is the undone element of buffer-undo-list.<br>=A0 =
=95 undo-delta is (position . offset) indicating how undo-redo should<br>=
=A0=A0=A0 modify a copy of undone-element in order to carry out the redo.<b=
r><br>When executing undo-only:<br>
=A0 =95 Assume pending-undo-list can be lazily computed<br>=A0 =95 Let undo=
-skip-set be an empty set of undo elements to skip<br>=A0 =95 Iterate over =
pending-undo-list until prefix-arg undos complete:<br>=A0=A0=A0 =95 If the =
element is in undo-skip-set:<br>
=A0=A0=A0=A0=A0 =95 Remove it from undo-skip-set<br>=A0=A0=A0=A0=A0 =95 Con=
tinue loop<br>=A0=A0=A0 =95 If the element is of the form for a redo elemen=
t:<br>=A0=A0=A0=A0=A0 =95 Insert its undone-element in the undo-skip-set<br=
>=A0=A0=A0 =95 Else undo the element<br><br>Using a BST for the undo-skip-s=
et would be appropriate, but I don&#39;t<br>
see that one is available to core Elisp code. A skip list data<br>structure=
 would be a simple option with similar performance<br>characteristics. Note=
: this is a different kind of &quot;skip&quot;, you can<br>duckduckgo &quot=
;skip lists&quot;.<br>
<br>In your earlier reply, you hinted that switching undo-only from using<b=
r>the undo-equiv-table to calling undo-make-selective-list might create<br>=
a noticable performance regression. The latter is O(N*N) for N sized<br>
undo history! I would expect undo-only will generally have an element<br>to=
 find, in which case, being able to compute next elements of<br>pending-und=
o-list as needed instead of in full upfront may be a<br>sufficient solution=
.<br>
<br>If it isn&#39;t sufficient, I can also make the algorithm O(N*log(N)).<=
br>One way to do this is using another skip list to store the<br>undo-delta=
s: sort by position, and at each node store the sum of the<br>offsets over =
the skip interval following that node. The analogous<br>
thing can be done with a BST: put the sum of a subtree&#39;s offsets at<br>=
each node. This is more complex in part because the sums need to be<br>upda=
ted during tree rotations.<br><br>There&#39;s another benefit to my propose=
d representation for redo<br>
elements. Consider the use case:<br>=A0 =95 Delete text X bytes large<br>=
=A0 =95 Do Y cycles of undo and redo<br><br>As I understand the current cod=
e, the size of undo history grows by<br>approximately X*Y. With this new wa=
y to represent redo elements, undo<br>
history grows approximately Y instead.<br><br>This proposal implies recursi=
ve calls to primitive-undo. The size of<br>the Lisp call stack would be a f=
unction of how deep redo records refer<br>to undone redo records. Maybe the=
re are reasonable ways to deal with<br>
that or maybe it&#39;s a non issue.<br><br>Are there examples of existing c=
ode putting (apply delta beg end<br>funname . args) into the buffer-undo-li=
st? I want to see what the<br>options might be for pushing redo elements in=
 that format. The best I<br>
can think of right now is a dynamically bound variable set only during<br>a=
n undo and examined in record functions in undo.c.<br><br>There&#39;s more =
I could say about other details, but I&#39;ll stop now to get<br>feedback o=
n the overall idea.<br>
<br></div>

--089e0122912c1fa7a504f04845c5--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 Jan 2014 03:19:01 +0000
Resent-Message-ID: <handler.16411.B16411.139010153826920 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.139010153826920
          (code B ref 16411); Sun, 19 Jan 2014 03:19:01 +0000
Received: (at 16411) by debbugs.gnu.org; 19 Jan 2014 03:18:58 +0000
Received: from localhost ([127.0.0.1]:56516 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W4iuX-000708-SS
	for submit <at> debbugs.gnu.org; Sat, 18 Jan 2014 22:18:58 -0500
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:63784)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1W4iuV-0006zw-F0
 for 16411 <at> debbugs.gnu.org; Sat, 18 Jan 2014 22:18:56 -0500
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjkFABK/CFFMCplR/2dsb2JhbABEhkezfoRJF3OCHgEBBAEjMyMFCwsaAhgOAgIUGA0kiB4Grl+SToEjjlSBEwOIYYl5kiCBXoMV
X-IPAS-Result: AjkFABK/CFFMCplR/2dsb2JhbABEhkezfoRJF3OCHgEBBAEjMyMFCwsaAhgOAgIUGA0kiB4Grl+SToEjjlSBEwOIYYl5kiCBXoMV
X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="45288803"
Received: from 76-10-153-81.dsl.teksavvy.com (HELO pastel.home)
 ([76.10.153.81])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 18 Jan 2014 22:18:55 -0500
Received: by pastel.home (Postfix, from userid 20848)
 id BEFB4603BA; Sat, 18 Jan 2014 22:18:54 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvd2jofyuc.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
 <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Li=sKXQ6pjdyk5E+rivUeOq5TF3aJ624Cdr=2ppMBtg@HIDDEN>
 <jwvmwizqttu.fsf-monnier+emacsbugs@HIDDEN>
 <jwvob3fpc3n.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Q2je+rOUordHv5WbLmWqKPmXFdm_LdBnmGCZ48wA5AQ@HIDDEN>
 <CAFM41H1-Ud8Kaw0hdShe8HgNUhfkKoyLG8_cxyUj0FeDB3TyRg@HIDDEN>
Date: Sat, 18 Jan 2014 22:18:54 -0500
In-Reply-To: <CAFM41H1-Ud8Kaw0hdShe8HgNUhfkKoyLG8_cxyUj0FeDB3TyRg@HIDDEN>
 (Barry OReilly's message of "Sat, 18 Jan 2014 19:58:14 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

> Where:
>   =E2=80=A2 delta, beg, end are as documented.
>   =E2=80=A2 undo-redo is a new function that copies undone-element, appli=
es
>     undo-delta, then calls primitive-undo on it.
>   =E2=80=A2 undone-element is the undone element of buffer-undo-list.
>   =E2=80=A2 undo-delta is (position . offset) indicating how undo-redo sh=
ould
>     modify a copy of undone-element in order to carry out the redo.

> When executing undo-only:
>   =E2=80=A2 Assume pending-undo-list can be lazily computed
>   =E2=80=A2 Let undo-skip-set be an empty set of undo elements to skip
>   =E2=80=A2 Iterate over pending-undo-list until prefix-arg undos complet=
e:
>     =E2=80=A2 If the element is in undo-skip-set:
>       =E2=80=A2 Remove it from undo-skip-set
>       =E2=80=A2 Continue loop
>     =E2=80=A2 If the element is of the form for a redo element:
>       =E2=80=A2 Insert its undone-element in the undo-skip-set
>     =E2=80=A2 Else undo the element

In which way would this help fixing bug 2 (I thought we had already
understood how to fix bug 2, BTW)?

More problematic: the step "Insert its undone-element in the
undo-skip-set" means that we skip this "redo" element, which means that
all the subsequent elements (until the matching undone-element) may have
incorrect buffer positions.

Luckily, you probably won't bump into any problem because all these
intermediate elements will themselves be redo elements or be in
undo-skip-set.  But it's still dangerous and wasteful (why not skip all
these elements in one swoop as we currently do with undo-equiv-table).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 Jan 2014 16:58:01 +0000
Resent-Message-ID: <handler.16411.B16411.139015064632767 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.139015064632767
          (code B ref 16411); Sun, 19 Jan 2014 16:58:01 +0000
Received: (at 16411) by debbugs.gnu.org; 19 Jan 2014 16:57:26 +0000
Received: from localhost ([127.0.0.1]:57251 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1W4vgb-0008WO-SF
	for submit <at> debbugs.gnu.org; Sun, 19 Jan 2014 11:57:26 -0500
Received: from mail-ob0-f182.google.com ([209.85.214.182]:38934)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1W4vgY-0008WF-Rj
 for 16411 <at> debbugs.gnu.org; Sun, 19 Jan 2014 11:57:23 -0500
Received: by mail-ob0-f182.google.com with SMTP id wm4so758719obc.13
 for <16411 <at> debbugs.gnu.org>; Sun, 19 Jan 2014 08:57:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=kFkl+If+gY6ffuPr39cgplqq0U33t1u4lYo5UaHnnKE=;
 b=AwVLSiJgf8krhExJBE8ryZb3o7UyiCWZjd6m0PwCs8Wb3P8Wj/lujOUcL9kR+8bOGn
 /xzGOigMzdAxxXKNNX1irYW0/g71pTe69yoSiBD0u8fwZcxWYOl1MjV9pmGLzJxsnvUZ
 Rkai62ptp6ttIoYmgl4jIWuN4ec8tIr45YVCa2auQBIPp/s/Pdcc8kyAIHPUArL12O8D
 D5ftOdvelXC3TyYCj0Y2IBYlazzIt28r87QdjzSK0fAg9wOseFLJK+0E2JOhTC+UUC7j
 ltAZ8agPwUxDRz04aXt0Ur1KiOktikWBtgvghY3DXgdY9Z7scaA20RY+ajYSSzec8KFN
 XSCg==
MIME-Version: 1.0
X-Received: by 10.182.153.226 with SMTP id vj2mr12023520obb.26.1390150642020; 
 Sun, 19 Jan 2014 08:57:22 -0800 (PST)
Received: by 10.76.21.84 with HTTP; Sun, 19 Jan 2014 08:57:21 -0800 (PST)
In-Reply-To: <jwvd2jofyuc.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
 <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Li=sKXQ6pjdyk5E+rivUeOq5TF3aJ624Cdr=2ppMBtg@HIDDEN>
 <jwvmwizqttu.fsf-monnier+emacsbugs@HIDDEN>
 <jwvob3fpc3n.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Q2je+rOUordHv5WbLmWqKPmXFdm_LdBnmGCZ48wA5AQ@HIDDEN>
 <CAFM41H1-Ud8Kaw0hdShe8HgNUhfkKoyLG8_cxyUj0FeDB3TyRg@HIDDEN>
 <jwvd2jofyuc.fsf-monnier+emacsbugs@HIDDEN>
Date: Sun, 19 Jan 2014 11:57:21 -0500
Message-ID: <CAFM41H3=YwZR6NpEQRr9kAcYUzL70pzf-txi51QQx2=mR2FRTQ@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=089e013d0dc033b4f404f055ab14
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e013d0dc033b4f404f055ab14
Content-Type: text/plain; charset=ISO-8859-1

> (I thought we had already understood how to fix bug 2, BTW)

No, we both agreed about how to fix bug 1, which isn't too hard or
intrusive. I'm talking about bug 2 now. I appreciate you taking the
time to discuss it with me. You said about it:

> IIUC, you're talking of skipping (e.g. in a non-region undo) the
> undos that took place during undo-in-region, right? If so, I don't
> have an answer for how we could do that, in general.

If you require the solution use undo-equiv-table, then I would have to
also admit to not having an answer.

> why not skip all these elements in one swoop as we currently do with
> undo-equiv-table

Because it would not be correct. I constructed recipe 2 in order to
demonstrate the incorrectness.

> In which way would this help fixing bug 2

Recipe 2 used an undo-in-region to trick the current undo-only
behavior into finding the wrong element to undo. Under my proposed
solution, undo-in-region creates a change group of redo elements, each
with a reference to its undone-element. This allows undo-only to find
the correct element to undo per the algorithm I described.

Why is it correct? undo-only wishes to find the most recent non redo
element A which is currently in the buffer (ie the net effect is it's
not undone). If A is reachable through an odd number of hops across
undo-element references, then it is undone, if even it is not undone.
If there exist paths to A both even and odd in length, then something
strange has happened to the undo history. The effect of skipping undo
elements as I described it is to exclude the ones with odd length
paths. For example, consider:

  A1 undoes A2 undoes A3 undoes A4 undoes A5

A2 and A4 will find themselves in the undo-skip-set, the others won't.
undo-only correctly finds A5 as the element to undo.

  B1 undoes B2 undoes B3 undoes B4 undoes B5 undoes B6

B2, B4, B6 will be skipped, so undo-only will have to find some other
non B element to undo, as it should in this case.

> the step "Insert its undone-element in the undo-skip-set" means that
> we skip this "redo" element, which means that all the subsequent
> elements (until the matching undone-element) may have incorrect
> buffer positions.

I explained this: I would rework the pending-undo-list computation to
be lazier, perhaps creating a get-next-pending-undo function instead
of computing the entire pending-undo-list upfront. undo-only would use
this function to get the next copy of an element of buffer-undo-list,
with positions adjusted using an index of undo-delta sums.
get-next-pending-undo would be part of "Iterate over
pending-undo-list", which means we are adjusting positions whether the
element will be skipped or not.

This rework to use a new get-next-pending-undo can be a self contained
patch which would benefit undo in region's performance right away,
even if undo-only doesn't use it after just the first patch.

> But it's still dangerous and wasteful

By dangerous do you mean incorrect? By wasteful do you mean non
performant? Maybe the discussion will be less confusing if we focus on
correctness first, then move to performance? Could you describe what
part of my proposal is incorrect?

--089e013d0dc033b4f404f055ab14
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; (I thought we had already understood how to fix bug 2=
, BTW)<br><br>No, we both agreed about how to fix bug 1, which isn&#39;t to=
o hard or<br>intrusive. I&#39;m talking about bug 2 now. I appreciate you t=
aking the<br>
time to discuss it with me. You said about it:<br><br>&gt; IIUC, you&#39;re=
 talking of skipping (e.g. in a non-region undo) the<br>&gt; undos that too=
k place during undo-in-region, right? If so, I don&#39;t<br>&gt; have an an=
swer for how we could do that, in general.<br>
<br>If you require the solution use undo-equiv-table, then I would have to<=
br>also admit to not having an answer.<br><br>&gt; why not skip all these e=
lements in one swoop as we currently do with<br>&gt; undo-equiv-table<br>
<br>Because it would not be correct. I constructed recipe 2 in order to<br>=
demonstrate the incorrectness.<br><br>&gt; In which way would this help fix=
ing bug 2<br><br>Recipe 2 used an undo-in-region to trick the current undo-=
only<br>
behavior into finding the wrong element to undo. Under my proposed<br>solut=
ion, undo-in-region creates a change group of redo elements, each<br>with a=
 reference to its undone-element. This allows undo-only to find<br>the corr=
ect element to undo per the algorithm I described.<br>
<br>Why is it correct? undo-only wishes to find the most recent non redo<br=
>element A which is currently in the buffer (ie the net effect is it&#39;s<=
br>not undone). If A is reachable through an odd number of hops across<br>
undo-element references, then it is undone, if even it is not undone.<br>If=
 there exist paths to A both even and odd in length, then something<br>stra=
nge has happened to the undo history. The effect of skipping undo<br>elemen=
ts as I described it is to exclude the ones with odd length<br>
paths. For example, consider:<br><br>=A0 A1 undoes A2 undoes A3 undoes A4 u=
ndoes A5<br><br>A2 and A4 will find themselves in the undo-skip-set, the ot=
hers won&#39;t.<br>undo-only correctly finds A5 as the element to undo.<br>
<br>=A0 B1 undoes B2 undoes B3 undoes B4 undoes B5 undoes B6<br><br>B2, B4,=
 B6 will be skipped, so undo-only will have to find some other<br>non B ele=
ment to undo, as it should in this case.<br><br>&gt; the step &quot;Insert =
its undone-element in the undo-skip-set&quot; means that<br>
&gt; we skip this &quot;redo&quot; element, which means that all the subseq=
uent<br>&gt; elements (until the matching undone-element) may have incorrec=
t<br>&gt; buffer positions.<br><br>I explained this: I would rework the pen=
ding-undo-list computation to<br>
be lazier, perhaps creating a get-next-pending-undo function instead<br>of =
computing the entire pending-undo-list upfront. undo-only would use<br>this=
 function to get the next copy of an element of buffer-undo-list,<br>with p=
ositions adjusted using an index of undo-delta sums.<br>
get-next-pending-undo would be part of &quot;Iterate over<br>pending-undo-l=
ist&quot;, which means we are adjusting positions whether the<br>element wi=
ll be skipped or not.<br><br>This rework to use a new get-next-pending-undo=
 can be a self contained<br>
patch which would benefit undo in region&#39;s performance right away,<br>e=
ven if undo-only doesn&#39;t use it after just the first patch.<br><br>&gt;=
 But it&#39;s still dangerous and wasteful<br><br>By dangerous do you mean =
incorrect? By wasteful do you mean non<br>
performant? Maybe the discussion will be less confusing if we focus on<br>c=
orrectness first, then move to performance? Could you describe what<br>part=
 of my proposal is incorrect?<br><br></div>

--089e013d0dc033b4f404f055ab14--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Feb 2014 18:52:01 +0000
Resent-Message-ID: <handler.16411.B16411.139240390825685 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.139240390825685
          (code B ref 16411); Fri, 14 Feb 2014 18:52:01 +0000
Received: (at 16411) by debbugs.gnu.org; 14 Feb 2014 18:51:48 +0000
Received: from localhost ([127.0.0.1]:52644 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WENrX-0006gC-DS
	for submit <at> debbugs.gnu.org; Fri, 14 Feb 2014 13:51:48 -0500
Received: from mail-oa0-f50.google.com ([209.85.219.50]:43667)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1WENrU-0006fp-VJ
 for 16411 <at> debbugs.gnu.org; Fri, 14 Feb 2014 13:51:45 -0500
Received: by mail-oa0-f50.google.com with SMTP id n16so15178435oag.9
 for <16411 <at> debbugs.gnu.org>; Fri, 14 Feb 2014 10:51:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
 :content-type; bh=NMJsq2UqwP7eKs/OuAyqYKRTHdYUQuWV8fhuqAX/IT4=;
 b=bzivNzYe4XvDSgmXHJB5fvjshfCIHMOszNK7VRO88Z7Mdwn4Xy66M5GWkjtOOsuHAX
 ZbiHsKYqqWPnW6NwZ14jnGO4bT5WV27chgYB2ZLIDWAxCCUOjso8XXJnJBGklLUW5/ST
 6AV/CJUC+HjlBJGD7GlkmrWKtn2Qx5CIriZSxTFF4SwlFjZmxsb5I/lCQ8tjrc9CiYgP
 8Jrz/Ha7t8abuHRJpgnyww91/hinPyR8ZUyWjHsCq9fnFW4GUro9y7bDQpXdDszxUZVn
 UFGZgzfD+2KJNLaoOKJa3r8VWM355V6peuBrUGENBtu/Waqwh0s2p8V4d5pGqy3kHrzE
 KTvw==
MIME-Version: 1.0
X-Received: by 10.60.229.4 with SMTP id sm4mr8037060oec.9.1392403898967; Fri,
 14 Feb 2014 10:51:38 -0800 (PST)
Received: by 10.76.21.84 with HTTP; Fri, 14 Feb 2014 10:51:38 -0800 (PST)
In-Reply-To: <CAFM41H3=YwZR6NpEQRr9kAcYUzL70pzf-txi51QQx2=mR2FRTQ@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <jwvbnzj5rlu.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3qDJ54Xj6o7Mt=yem9LwviPqhQbdk3QyFJ0vD_REF21g@HIDDEN>
 <jwveh4f2lya.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Li=sKXQ6pjdyk5E+rivUeOq5TF3aJ624Cdr=2ppMBtg@HIDDEN>
 <jwvmwizqttu.fsf-monnier+emacsbugs@HIDDEN>
 <jwvob3fpc3n.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3Q2je+rOUordHv5WbLmWqKPmXFdm_LdBnmGCZ48wA5AQ@HIDDEN>
 <CAFM41H1-Ud8Kaw0hdShe8HgNUhfkKoyLG8_cxyUj0FeDB3TyRg@HIDDEN>
 <jwvd2jofyuc.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H3=YwZR6NpEQRr9kAcYUzL70pzf-txi51QQx2=mR2FRTQ@HIDDEN>
Date: Fri, 14 Feb 2014 13:51:38 -0500
Message-ID: <CAFM41H3Ld_nqUJhQZwmfYAKxo3EotFHDc0csr7Zy4w=AEPYhJw@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11362860c82e0e04f2624bfb
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

--001a11362860c82e0e04f2624bfb
Content-Type: text/plain; charset=ISO-8859-1

Here's another bug with recipe. Again, each "insert" should be a
change group.

  * ./src/emacs -Q
  * In *scratch* at least twice:
    * Insert "aaa"
    * Undo
  * Select the entire buffer
  * Undo in region with prefix-arg 4
  * Observe the wrongful deletion of the string: "fer." in the Lisp
    comment.

undo-elt-in-region has a discrepency between whether (TEXT . POSITION)
and (BEGIN . END) are in the region:

  ;; (BEGIN . END)
  (and (>= (car undo-elt) start)
       (<= (cdr undo-elt) end))
        ^^

  ;; (TEXT . POSITION)
  (and (>= (abs (cdr undo-elt)) start)
       (< (abs (cdr undo-elt)) end))
        ^

One is compared to the end by <= and the other by <. Consequently,
(192 . 195) is deemed in the region, (aaa . 192) outside the region.
With (aaa . 192) outside the region, all subsequent positions of
undo-list-copy are decremented by three, including the next (192 .
195) which becomes (189 . 192). (189 . 192) is deemed in the region,
but that's not valid given the restoration of "aaa" was just excluded.
It's now pear shaped.

I'm collecting these bugs related to the undo system in one bug report
because that is the most organized way for me to address them.

--001a11362860c82e0e04f2624bfb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Here&#39;s another bug with recipe. Again, each &quot;inse=
rt&quot; should be a<br>change group.<br><br>&nbsp; &bull; ./src/emacs -Q<b=
r>&nbsp; &bull; In *scratch* at least twice:<br>&nbsp;&nbsp;&nbsp; &bull; I=
nsert &quot;aaa&quot;<br>&nbsp;&nbsp;&nbsp; &bull; Undo<br>
&nbsp; &bull; Select the entire buffer<br>&nbsp; &bull; Undo in region with=
 prefix-arg 4<br>&nbsp; &bull; Observe the wrongful deletion of the string:=
 &quot;fer.&quot; in the Lisp<br>&nbsp;&nbsp;&nbsp; comment.<br><br>undo-el=
t-in-region has a discrepency between whether (TEXT . POSITION)<br>
and (BEGIN . END) are in the region:<br><br>&nbsp; ;; (BEGIN . END)<br>&nbs=
p; (and (&gt;=3D (car undo-elt) start)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; (&lt;=3D (cdr undo-elt) end))<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; ^^<br><br>&nbsp; ;; (TEXT . POSITION)<br>&nbsp; (and (&gt;=3D (abs (cd=
r undo-elt)) start)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (&lt; (abs (cdr undo-elt)) end))<br>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^<br><br>One is compared to the en=
d by &lt;=3D and the other by &lt;. Consequently,<br>(192 . 195) is deemed =
in the region, (aaa . 192) outside the region.<br>With (aaa . 192) outside =
the region, all subsequent positions of<br>
undo-list-copy are decremented by three, including the next (192 .<br>195) =
which becomes (189 . 192). (189 . 192) is deemed in the region,<br>but that=
&#39;s not valid given the restoration of &quot;aaa&quot; was just excluded=
.<br>
It&#39;s now pear shaped.<br><br>I&#39;m collecting these bugs related to t=
he undo system in one bug report<br>because that is the most organized way =
for me to address them.<br><br></div>

--001a11362860c82e0e04f2624bfb--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
In-Reply-To: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Feb 2014 22:30:02 +0000
Resent-Message-ID: <handler.16411.B16411.139241695118637 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.139241695118637
          (code B ref 16411); Fri, 14 Feb 2014 22:30:02 +0000
Received: (at 16411) by debbugs.gnu.org; 14 Feb 2014 22:29:11 +0000
Received: from localhost ([127.0.0.1]:52744 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WERFu-0004qU-DN
	for submit <at> debbugs.gnu.org; Fri, 14 Feb 2014 17:29:10 -0500
Received: from mail-ob0-f171.google.com ([209.85.214.171]:40896)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1WERFs-0004qB-1y
 for 16411 <at> debbugs.gnu.org; Fri, 14 Feb 2014 17:29:08 -0500
Received: by mail-ob0-f171.google.com with SMTP id wp4so14696558obc.30
 for <16411 <at> debbugs.gnu.org>; Fri, 14 Feb 2014 14:29:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:date:message-id:subject:from:to:content-type;
 bh=NG1zQllhrI1gADnwmCNuSzwRvF9+yb/6M0ifXseAK0o=;
 b=BmdZf6109sVNHJOU9DV7QKzxtx92049cSFu7lnK14hKXoGyQvnQMavC+Xu+J6oenFu
 SYoLm2ZMvIpCvvAs7uUJaPLmsqX03aY/z0lVgFbm7wvgfpLEoyaWUq4gaM4ELeSGN5Se
 Ofxx/jniGXONBeGL8g5Su7z8jj0xBWHDuKgepyfE8XDhuukfAdZNwNg6uM4lpgpBpxk6
 v1pKxyYBFrPNWMSLLZBvv088kkzu3HPYuNPK2QgxitaZ6/MZuTCorvCNwLypGmqXHM93
 Uji6DkKz3/gmsFblOhMAsVa8TMtFC3WFLyAP2A5qnArL0N3hqLOuoxeUmnSEWhWh5vVy
 Egpg==
MIME-Version: 1.0
X-Received: by 10.182.28.134 with SMTP id b6mr8763223obh.27.1392416942165;
 Fri, 14 Feb 2014 14:29:02 -0800 (PST)
Received: by 10.76.21.84 with HTTP; Fri, 14 Feb 2014 14:29:02 -0800 (PST)
Date: Fri, 14 Feb 2014 17:29:02 -0500
Message-ID: <CAFM41H0Aoj4BJ-NnFJpnBLPYExZnK9KrzU27Rc1ciKLYj8U_mw@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c2903c3794fd04f26555f9
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c2903c3794fd04f26555f9
Content-Type: text/plain; charset=ISO-8859-1

> * ./src/emacs -Q
> * In *scratch* at least twice:
>   * Insert "aaa"
>   * Undo
> * Select the entire buffer
> * Undo in region with prefix-arg 4
> * Observe the wrongful deletion of the string: "fer." in the Lisp
>   comment.

A more concise recipe:

  * ./src/emacs -Q
  * In *scratch* insert "aaa"
  * Undo
  * Select the entire buffer
  * Undo in region
  * Observe the wrongful deletion of the period in the Lisp comment.

--001a11c2903c3794fd04f26555f9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; &bull; ./src/emacs -Q<br>&gt; &bull; In *scratch* at =
least twice:<br>&gt;&nbsp;&nbsp; &bull; Insert &quot;aaa&quot;<br>&gt;&nbsp=
;&nbsp; &bull; Undo<br>&gt; &bull; Select the entire buffer<br>&gt; &bull; =
Undo in region with prefix-arg 4<br>&gt; &bull; Observe the wrongful deleti=
on of the string: &quot;fer.&quot; in the Lisp<br>
&gt;&nbsp;&nbsp; comment.<br><br>A more concise recipe:<br><br>&nbsp; &bull=
; ./src/emacs -Q<br>&nbsp; &bull; In *scratch* insert &quot;aaa&quot;<br>&n=
bsp; &bull; Undo<br>&nbsp; &bull; Select the entire buffer<br>&nbsp; &bull;=
 Undo in region<br>&nbsp; &bull; Observe the wrongful deletion of the perio=
d in the Lisp comment.<br>
<br></div>

--001a11c2903c3794fd04f26555f9--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
In-Reply-To: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 18 Feb 2014 17:42:02 +0000
Resent-Message-ID: <handler.16411.B16411.139274528025638 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.139274528025638
          (code B ref 16411); Tue, 18 Feb 2014 17:42:02 +0000
Received: (at 16411) by debbugs.gnu.org; 18 Feb 2014 17:41:20 +0000
Received: from localhost ([127.0.0.1]:58743 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WFofW-0006fR-Pf
	for submit <at> debbugs.gnu.org; Tue, 18 Feb 2014 12:41:19 -0500
Received: from mail-oa0-f42.google.com ([209.85.219.42]:39267)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1WFofT-0006fA-Cg
 for 16411 <at> debbugs.gnu.org; Tue, 18 Feb 2014 12:41:16 -0500
Received: by mail-oa0-f42.google.com with SMTP id i7so19599752oag.15
 for <16411 <at> debbugs.gnu.org>; Tue, 18 Feb 2014 09:41:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:date:message-id:subject:from:to:content-type;
 bh=90yGC29SL3/CGmWz8BfvU0AoC24OSvhrNGq5JNI6Zrs=;
 b=mJZsxwl41uJyZiDkyz7G00L9ePL3iOwdrhuo7q4F4ES9v0X5oTtMhXvHyBnjCd/1Hv
 fyvpuNusPMjoUpjC+Pmk5rfhLR8BYIgPTGa6Z8U1iChsIjuFZ7INMrp6iP4NOgmwSvQ/
 ZkxxV8YJQ8129wNDJ/W2vVA9u3phls9dtTtxtaDOygYM+5ZHecXgv8xxATFI2EE+gaQu
 NHy2esZjF+sE3IhQSdtyXtDO5MFKfQ4uBcBulRBajXerRKDm0mtFgb9/WuXdwXSno86l
 +2xMQv5xll232VrhFvjBolXsaFK61dWWGukI556tAoLtzpdUeuyuYALvZ8F09N9fgaoB
 3oEw==
MIME-Version: 1.0
X-Received: by 10.182.28.134 with SMTP id b6mr27151841obh.27.1392745239012;
 Tue, 18 Feb 2014 09:40:39 -0800 (PST)
Received: by 10.76.21.84 with HTTP; Tue, 18 Feb 2014 09:40:38 -0800 (PST)
Date: Tue, 18 Feb 2014 12:40:38 -0500
Message-ID: <CAFM41H1-RsyTCe5nkrQK5tavSqNOh-00ZFrmRpvQ4XTu0nASbw@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c2903c3bea2c04f2b1c55c
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c2903c3bea2c04f2b1c55c
Content-Type: text/plain; charset=ISO-8859-1

>   ;; (BEGIN . END)
>   (and (>= (car undo-elt) start)
>        (<= (cdr undo-elt) end))
>         ^^
>
>   ;; (TEXT . POSITION)
>   (and (>= (abs (cdr undo-elt)) start)
>        (< (abs (cdr undo-elt)) end))
>         ^

Using 'git log -L' on these two code fragments, I found the (BEGIN .
END) case changed in this commit to "Fix one-off error at END".

commit 9debee7a5e6ebc0c32141619248e7390f1476946
Author: Richard M. Stallman <rms@HIDDEN>
Date:   Mon Sep 9 00:27:30 2002 +0000

    (undo-elt-in-region): Fix one-off error at END.
    (forward-visible-line): Handle invisibility by ignoring
    invisible newlines.  Also include entire invisible lines beyond
    the stopping point.

diff --git a/lisp/simple.el b/lisp/simple.el
index bfef653..d9ae114 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1089,7 +1089,7 @@ we stop and ignore all further elements."
 If it crosses the edge, we return nil."
   (cond ((integerp undo-elt)
         (and (>= undo-elt start)
-             (<  undo-elt end)))
+             (<= undo-elt end)))
        ((eq undo-elt nil)
         t)
        ((atom undo-elt)
@@ -1109,16 +1109,16 @@ If it crosses the edge, we return nil."
                   (cons alist-elt undo-adjusted-markers)))
           (and (cdr alist-elt)
                (>= (cdr alist-elt) start)
-               (< (cdr alist-elt) end))))
+               (<= (cdr alist-elt) end))))
        ((null (car undo-elt))
         ;; (nil PROPERTY VALUE BEG . END)
         (let ((tail (nthcdr 3 undo-elt)))
           (and (>= (car tail) start)
-               (< (cdr tail) end))))
+               (<= (cdr tail) end))))
        ((integerp (car undo-elt))
         ;; (BEGIN . END)
         (and (>= (car undo-elt) start)
-             (< (cdr undo-elt) end)))))
+             (<= (cdr undo-elt) end)))))

 (defun undo-elt-crosses-region (undo-elt start end)
   "Test whether UNDO-ELT crosses one edge of that region START ... END.

This didn't change the (TEXT . POSITION) case, which hasn't changed
since 1998 when it was first introduced. Maybe it was forgotten in the
above 2002 change?

Anyway, I made this change locally:

diff --git a/lisp/simple.el b/lisp/simple.el
index b90382d..01d4f19 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2434,7 +2434,7 @@ If it crosses the edge, we return nil."
        ((stringp (car undo-elt))
         ;; (TEXT . POSITION)
         (and (>= (abs (cdr undo-elt)) start)
-             (< (abs (cdr undo-elt)) end)))
+             (<= (abs (cdr undo-elt)) end)))
        ((and (consp undo-elt) (markerp (car undo-elt)))
         ;; This is a marker-adjustment element (MARKER . ADJUSTMENT).
         ;; See if MARKER is inside the region.

and I didn't witness the incorrect behavior from undo in region.

Another justification for this change, in addition to fixing the
buffer corruption my recipe demonstrates, is that without it, a
deletion at the EOB is inaccessible via undo in region.

--001a11c2903c3bea2c04f2b1c55c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=A0=A0 ;; (BEGIN . END)<br>&gt;=A0=A0 (and (&gt;=3D (c=
ar undo-elt) start)<br>&gt;=A0=A0=A0=A0=A0=A0=A0 (&lt;=3D (cdr undo-elt) en=
d))<br>&gt;=A0=A0=A0=A0=A0=A0=A0=A0 ^^<br>&gt; <br>&gt;=A0=A0 ;; (TEXT . PO=
SITION)<br>&gt;=A0=A0 (and (&gt;=3D (abs (cdr undo-elt)) start)<br>
&gt;=A0=A0=A0=A0=A0=A0=A0 (&lt; (abs (cdr undo-elt)) end))<br>&gt;=A0=A0=A0=
=A0=A0=A0=A0=A0 ^<br><br>Using &#39;git log -L&#39; on these two code fragm=
ents, I found the (BEGIN .<br>END) case changed in this commit to &quot;Fix=
 one-off error at END&quot;.<br>
<br>commit 9debee7a5e6ebc0c32141619248e7390f1476946<br>Author: Richard M. S=
tallman &lt;<a href=3D"mailto:rms@HIDDEN">rms@HIDDEN</a>&gt;<br>Date:=A0=
=A0 Mon Sep 9 00:27:30 2002 +0000<br><br>=A0=A0=A0 (undo-elt-in-region): Fi=
x one-off error at END.<br>
=A0=A0=A0 (forward-visible-line): Handle invisibility by ignoring<br>=A0=A0=
=A0 invisible newlines.=A0 Also include entire invisible lines beyond<br>=
=A0=A0=A0 the stopping point.<br><br>diff --git a/lisp/simple.el b/lisp/sim=
ple.el<br>index bfef653..d9ae114 100644<br>
--- a/lisp/simple.el<br>+++ b/lisp/simple.el<br>@@ -1089,7 +1089,7 @@ we st=
op and ignore all further elements.&quot;<br>=A0If it crosses the edge, we =
return nil.&quot;<br>=A0=A0 (cond ((integerp undo-elt)<br>=A0=A0=A0=A0=A0=
=A0=A0=A0 (and (&gt;=3D undo-elt start)<br>
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt;=A0 undo-elt end)))<br>+=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt;=3D undo-elt end)))<br>=A0=A0=A0=A0=A0=
=A0=A0 ((eq undo-elt nil)<br>=A0=A0=A0=A0=A0=A0=A0=A0 t)<br>=A0=A0=A0=A0=A0=
=A0=A0 ((atom undo-elt)<br>@@ -1109,16 +1109,16 @@ If it crosses the edge, =
we return nil.&quot;<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (cons alist-elt undo=
-adjusted-markers)))<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (and (cdr alist-elt)=
<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&gt;=3D (cdr alist-elt) =
start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt; (cdr alist-elt)=
 end))))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt;=3D (cdr alist=
-elt) end))))<br>
=A0=A0=A0=A0=A0=A0=A0 ((null (car undo-elt))<br>=A0=A0=A0=A0=A0=A0=A0=A0 ;;=
 (nil PROPERTY VALUE BEG . END)<br>=A0=A0=A0=A0=A0=A0=A0=A0 (let ((tail (nt=
hcdr 3 undo-elt)))<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (and (&gt;=3D (car tai=
l) start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt; (cdr tail) e=
nd))))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt;=3D (cdr tail) e=
nd))))<br>
=A0=A0=A0=A0=A0=A0=A0 ((integerp (car undo-elt))<br>=A0=A0=A0=A0=A0=A0=A0=
=A0 ;; (BEGIN . END)<br>=A0=A0=A0=A0=A0=A0=A0=A0 (and (&gt;=3D (car undo-el=
t) start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt; (cdr undo-elt) end=
)))))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt;=3D (cdr undo-elt) end)=
))))<br>=A0<br>=A0(defun undo-elt-crosses-region (undo-elt start end)<br>
=A0=A0 &quot;Test whether UNDO-ELT crosses one edge of that region START ..=
. END.<br><br>This didn&#39;t change the (TEXT . POSITION) case, which hasn=
&#39;t changed<br>since 1998 when it was first introduced. Maybe it was for=
gotten in the<br>
above 2002 change?<br><br>Anyway, I made this change locally:<br><br>diff -=
-git a/lisp/simple.el b/lisp/simple.el<br>index b90382d..01d4f19 100644<br>=
--- a/lisp/simple.el<br>+++ b/lisp/simple.el<br>@@ -2434,7 +2434,7 @@ If it=
 crosses the edge, we return nil.&quot;<br>
=A0=A0=A0=A0=A0=A0=A0 ((stringp (car undo-elt))<br>=A0=A0=A0=A0=A0=A0=A0=A0=
 ;; (TEXT . POSITION)<br>=A0=A0=A0=A0=A0=A0=A0=A0 (and (&gt;=3D (abs (cdr u=
ndo-elt)) start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt; (abs (cdr u=
ndo-elt)) end)))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (&lt;=3D (abs (cd=
r undo-elt)) end)))<br>
=A0=A0=A0=A0=A0=A0=A0 ((and (consp undo-elt) (markerp (car undo-elt)))<br>=
=A0=A0=A0=A0=A0=A0=A0=A0 ;; This is a marker-adjustment element (MARKER . A=
DJUSTMENT).<br>=A0=A0=A0=A0=A0=A0=A0=A0 ;; See if MARKER is inside the regi=
on.<br><br>and I didn&#39;t witness the incorrect behavior from undo in reg=
ion.<br>
<br>Another justification for this change, in addition to fixing the<br>buf=
fer corruption my recipe demonstrates, is that without it, a<br>deletion at=
 the EOB is inaccessible via undo in region.<br><br></div>

--001a11c2903c3bea2c04f2b1c55c--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo in region corrupts existing text
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
In-Reply-To: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 26 Feb 2014 15:21:02 +0000
Resent-Message-ID: <handler.16411.B16411.139342802032509 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.139342802032509
          (code B ref 16411); Wed, 26 Feb 2014 15:21:02 +0000
Received: (at 16411) by debbugs.gnu.org; 26 Feb 2014 15:20:20 +0000
Received: from localhost ([127.0.0.1]:41424 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WIgHT-0008SH-Kr
	for submit <at> debbugs.gnu.org; Wed, 26 Feb 2014 10:20:20 -0500
Received: from mail-ob0-f172.google.com ([209.85.214.172]:34808)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1WIgHR-0008S9-SM
 for 16411 <at> debbugs.gnu.org; Wed, 26 Feb 2014 10:20:18 -0500
Received: by mail-ob0-f172.google.com with SMTP id wm4so901300obc.31
 for <16411 <at> debbugs.gnu.org>; Wed, 26 Feb 2014 07:20:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:date:message-id:subject:from:to:content-type;
 bh=1mFaScK2ZF6+UtqImhNOLAaObTw23xqDQM+xqoN9Ges=;
 b=mhOqXm9eSw709PDCOaXzGKJn9q0DzAKKoR+eyAdXxySEyfcYRDZhJBePdZ6L+DlTFW
 gEJ9rYZ8/JSb70GMTP7+cVD0CuIeuFjejL2VFNKAwnf0c3Jp6ABQy2RIFGqnT88+UbqY
 iirFO8U5iKn9gHvryJyFdrT0zpg5oEqXf4rTR/fnFNKVHLqbsW5jXWD8nNOovryZCfVG
 vR6clWSivmJ2sZm58ygEvpZCjuT2zq2tDphxqdeDU4SaRPMgaBCxYd6lx5J6FvbU412w
 ctHXZ8Sy0Xg+xufUt7N8AvixlZV6LJvm/+FuoZdlp0fChyFn6sY9y+TFzRKhgt9Zdhl2
 FIjw==
MIME-Version: 1.0
X-Received: by 10.60.123.74 with SMTP id ly10mr6997005oeb.14.1393428017303;
 Wed, 26 Feb 2014 07:20:17 -0800 (PST)
Received: by 10.76.21.84 with HTTP; Wed, 26 Feb 2014 07:20:17 -0800 (PST)
Date: Wed, 26 Feb 2014 10:20:17 -0500
Message-ID: <CAFM41H2EkEmOMhNT--3LLzrUTdhrX_UFbOwM=X2Fir0Z5iWGUA@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7b5d42fcfdfced04f350bd9e
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--047d7b5d42fcfdfced04f350bd9e
Content-Type: text/plain; charset=ISO-8859-1

Ping. Is my fix to the bug described at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16411#38 acceptable to
install? Here is the patch again:

diff --git a/lisp/simple.el b/lisp/simple.el
index b90382d..01d4f19 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2434,7 +2434,7 @@ If it crosses the edge, we return nil."
        ((stringp (car undo-elt))
         ;; (TEXT . POSITION)
         (and (>= (abs (cdr undo-elt)) start)
-             (< (abs (cdr undo-elt)) end)))
+             (<= (abs (cdr undo-elt)) end)))
        ((and (consp undo-elt) (markerp (car undo-elt)))
         ;; This is a marker-adjustment element (MARKER . ADJUSTMENT).
         ;; See if MARKER is inside the region.

--047d7b5d42fcfdfced04f350bd9e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ping. Is my fix to the bug described at<br><a href=3D"http=
://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D16411#38">http://debbugs.gnu.org=
/cgi/bugreport.cgi?bug=3D16411#38</a> acceptable to<br>install? Here is the=
 patch again:<br>
<br>diff --git a/lisp/simple.el b/lisp/simple.el<br>index b90382d..01d4f19 =
100644<br>--- a/lisp/simple.el<br>+++ b/lisp/simple.el<br>@@ -2434,7 +2434,=
7 @@ If it crosses the edge, we return nil.&quot;<br>=A0=A0=A0=A0=A0=A0=A0 =
((stringp (car undo-elt))<br>
=A0=A0=A0=A0=A0=A0=A0=A0 ;; (TEXT . POSITION)<br>=A0=A0=A0=A0=A0=A0=A0=A0 (=
and (&gt;=3D (abs (cdr undo-elt)) start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 (&lt; (abs (cdr undo-elt)) end)))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 (&lt;=3D (abs (cdr undo-elt)) end)))<br>=A0=A0=A0=A0=A0=A0=A0 ((and =
(consp undo-elt) (markerp (car undo-elt)))<br>
=A0=A0=A0=A0=A0=A0=A0=A0 ;; This is a marker-adjustment element (MARKER . A=
DJUSTMENT).<br>=A0=A0=A0=A0=A0=A0=A0=A0 ;; See if MARKER is inside the regi=
on.<br><br></div>

--047d7b5d42fcfdfced04f350bd9e--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo in region corrupts existing text
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 27 Feb 2014 05:06:02 +0000
Resent-Message-ID: <handler.16411.B16411.139347751315840 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <at> debbugs.gnu.org
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.139347751315840
          (code B ref 16411); Thu, 27 Feb 2014 05:06:02 +0000
Received: (at 16411) by debbugs.gnu.org; 27 Feb 2014 05:05:13 +0000
Received: from localhost ([127.0.0.1]:42050 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WIt9k-00047Q-Lz
	for submit <at> debbugs.gnu.org; Thu, 27 Feb 2014 00:05:13 -0500
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:5482)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WIt9i-00047F-0H
 for 16411 <at> debbugs.gnu.org; Thu, 27 Feb 2014 00:05:10 -0500
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpaMk/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GDMEhkQoDiGGOSI1RgV6DFQ
X-IPAS-Result: Av4EABK/CFFFpaMk/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GDMEhkQoDiGGOSI1RgV6DFQ
X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="48864619"
Received: from 69-165-163-36.dsl.teksavvy.com (HELO ceviche.home)
 ([69.165.163.36])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 27 Feb 2014 00:05:08 -0500
Received: by ceviche.home (Postfix, from userid 20848)
 id C7ABA66099; Thu, 27 Feb 2014 00:02:58 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvd2i9gnbm.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
 <CAFM41H2EkEmOMhNT--3LLzrUTdhrX_UFbOwM=X2Fir0Z5iWGUA@HIDDEN>
Date: Thu, 27 Feb 2014 00:02:58 -0500
In-Reply-To: <CAFM41H2EkEmOMhNT--3LLzrUTdhrX_UFbOwM=X2Fir0Z5iWGUA@HIDDEN>
 (Barry OReilly's message of "Wed, 26 Feb 2014 10:20:17 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

> Ping. Is my fix to the bug described at
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16411#38 acceptable to
> install? Here is the patch again:

I think so, yes, but please add a corresponding ERT test case.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
In-Reply-To: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 13 May 2014 15:02:02 +0000
Resent-Message-ID: <handler.16411.B16411.139999330327723 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 16411 <16411 <at> debbugs.gnu.org>, Stefan Monnier <monnier@HIDDEN>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.139999330327723
          (code B ref 16411); Tue, 13 May 2014 15:02:02 +0000
Received: (at 16411) by debbugs.gnu.org; 13 May 2014 15:01:43 +0000
Received: from localhost ([127.0.0.1]:34157 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WkED7-0007D0-KH
	for submit <at> debbugs.gnu.org; Tue, 13 May 2014 11:01:43 -0400
Received: from mail-oa0-f43.google.com ([209.85.219.43]:60526)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1WkED4-0007Cd-QT
 for 16411 <at> debbugs.gnu.org; Tue, 13 May 2014 11:01:40 -0400
Received: by mail-oa0-f43.google.com with SMTP id l6so536093oag.2
 for <16411 <at> debbugs.gnu.org>; Tue, 13 May 2014 08:01:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:date:message-id:subject:from:to:content-type;
 bh=sndGun9iMKqlJu2mvWe4AWK6GEZyrHY4tPxL+b35LkU=;
 b=o0qcdDa0XhhNRQKmszN5es/ijXVn8cfHjQ3r4F9+8JuKi5SoaLyYgomXgYUafhnbgn
 CiROwgrA+acYZ/UFIxCFLy4gtzL07t+US8VclyxpBc+KHCLWABxorprKJ6Q42tVEz+kp
 Q4oSG/K/HmBytswwV9+lzm7RFDTdUoSGZJbkEs4LMy/UmMIOcvjhxOQ0wLmDYI4VP2w2
 IW7spPGqzWefvaIaR+c6Ffnb3Y9Bil5FbMauckGV00SXzwRh3xCIDp5lHZBrwjnxS/RN
 akp8RMuvfccNMkhtojQm1+ThcNrlo6pbkNgyKIPMUNSdttAgQUaJPv0jr8h8ahG4mo7K
 WgZA==
MIME-Version: 1.0
X-Received: by 10.182.225.137 with SMTP id rk9mr41938738obc.51.1399993292979; 
 Tue, 13 May 2014 08:01:32 -0700 (PDT)
Received: by 10.76.6.44 with HTTP; Tue, 13 May 2014 08:01:32 -0700 (PDT)
Date: Tue, 13 May 2014 11:01:32 -0400
Message-ID: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

I am pursuing a solution more like the first one I suggested in bug
16411 and have a preliminary patch I would like to get some feedback
on. undo-tests pass but the patch does not fix the bug yet. The patch
does two major things:

   1: Defines and populates a new undo-redo-table
   2: Uses closures to lazily compute pending undo elements

Item 1 is the crucial one. The undo-redo-table is somewhat like
undo-equiv-table, except that instead of mapping equal buffer states,
it maps undo elements to what they undid. This conveys better
information.

Mapping equal buffer states with undo-equiv-table is not workable,
because undos in region generally don't return the user to a buffer
state that actually existed before. Consider: insert A, insert B, undo
in region of A. The buffer has just B for the first time.

Existing use of undo-equiv-table can readily switch to use
undo-redo-table, as described in the obsoletion note of the patch. The
converse, using undo-equiv-table instead of undo-redo-table, would
require traversing backwards in the singly linked list.

The reason undo-redo-table maps at the element level, as opposed to
the change group level, is because in the case of undo in region with
a prefix arg, the newly created change group needs to reference
subsets of potentially many prior change groups.

Having undo elements reference what they undid would help solve
several issues:

   1: undo-only in region doesn't work.
   2: Normal undo-only after an undo in region doesn't work. I've
      previously outlined how the solution would use the
      undo-redo-table.
   3: Undo in region has counter intuitive behavior as described in
      the FIXME of simple.el describing undo in region.
   4: Deleting X bytes, then doing Y iterations of undo and redo
      causes undo history to grow about X*Y. To grow proportional to Y
      should be achievable: set undo-in-progress to the in progress
      element, and the C level undo recording to use it and
      undo-redo-table to find the eq Lisp_String.
   5: Undo Tree should more tightly integrate with the builtin undo
      system. To do so, it needs sufficient information to visualize
      the buffer-undo-list as a tree. Undo Tree has a means to
      visualize undo in regions, so undo-equiv-table is inadequate.

There are variations on how elements could reference what they undid,
but fundamentally I think it is essential. I wish to know how you like
the direction the patch is going as I proceed to solve some problems
building upon it.

The patch ignores whitespace.

diff --git a/lisp/simple.el b/lisp/simple.el
index 1484339..09b3a5f 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2054,20 +2054,32 @@ Go to the history element by the absolute
history position HIST-POS."
 ;Put this on C-x u, so we can force that rather than C-_ into startup msg
 (define-obsolete-function-alias 'advertised-undo 'undo "23.2")

+(defvar undo-redo-table (make-hash-table :test 'eq :weakness t)
+  "Hash table mapping undo elements created by an undo command to
+the undo element they undid.  Specifically, the keys and values
+are eq to cons of buffer-undo-list.  The hash table is weak so as
+truncated undo elements can be garbage collected.")
 (defconst undo-equiv-table (make-hash-table :test 'eq :weakness t)
   "Table mapping redo records to the corresponding undo one.
 A redo record for undo-in-region maps to t.
 A redo record for ordinary undo maps to the following (earlier) undo.")
+(make-obsolete-variable
+ 'undo-equiv-table
+ "Use undo-redo-table instead.  For non regional undos, (gethash
+k undo-equiv-table) is the same as taking (gethash k
+undo-redo-table) and scanning forward one change group."
+ "24.5")

 (defvar undo-in-region nil
-  "Non-nil if `pending-undo-list' is not just a tail of `buffer-undo-list'.")
+  "Non-nil during an undo in region.")

 (defvar undo-no-redo nil
   "If t, `undo' doesn't go through redo entries.")

 (defvar pending-undo-list nil
-  "Within a run of consecutive undo commands, list remaining to be undone.
-If t, we undid all the way to the end of it.")
+  "Within a run of consecutive undo commands, is a tail of
+buffer-undo-list for remaining undo elements, or a closure to
+generate them.  If t, there is no more to undo.")

 (defun undo (&optional arg)
   "Undo some previous changes.
@@ -2115,9 +2127,10 @@ as an argument limits undo to changes within
the current region."
       (undo-more 1))
     ;; If we got this far, the next command should be a consecutive undo.
     (setq this-command 'undo)
-    ;; Check to see whether we're hitting a redo record, and if
-    ;; so, ask the user whether she wants to skip the redo/undo pair.
-    (let ((equiv (gethash pending-undo-list undo-equiv-table)))
+    ;; Check to see whether we're hitting a redo record
+    (let ((equiv (if (functionp pending-undo-list)
+                     t
+                   (gethash pending-undo-list undo-equiv-table))))
       (or (eq (selected-window) (minibuffer-window))
          (setq message (format "%s%s!"
                                 (if (or undo-no-redo (not equiv))
@@ -2202,40 +2215,48 @@ Some change-hooks test this variable to do
something different.")
   "Undo back N undo-boundaries beyond what was already undone recently.
 Call `undo-start' to get ready to undo recent changes,
 then call `undo-more' one or more times to undo them."
-  (or (listp pending-undo-list)
+  (when (eq pending-undo-list t)
     (user-error (concat "No further undo information"
                         (and undo-in-region " for region"))))
   (let ((undo-in-progress t))
-    ;; Note: The following, while pulling elements off
-    ;; `pending-undo-list' will call primitive change functions which
-    ;; will push more elements onto `buffer-undo-list'.
-    (setq pending-undo-list (primitive-undo n pending-undo-list))
-    (if (null pending-undo-list)
+    ;; Note: The following changes the buffer, and so calls primitive
+    ;; change functions that push more elements onto
+    ;; `buffer-undo-list'.
+    (unless (if (functionp pending-undo-list)
+                (undo-using-generator pending-undo-list n)
+              (setq pending-undo-list
+                    (primitive-undo n pending-undo-list)))
+      ;; Reached the end of undo history
       (setq pending-undo-list t))))

 (defun primitive-undo (n list)
-  "Undo N records from the front of the list LIST.
+  "Undo N change groups from the front of the list LIST.
 Return what remains of the list."
+  (undo-using-generator
+   (lambda (&optional option)
+     (prog1 (cons (car list) list)
+       (unless (eq option 'peek) (pop list))))
+   n)
+  list)

-  ;; This is a good feature, but would make undo-start
-  ;; unable to do what is expected.
-  ;;(when (null (car (list)))
-  ;;  ;; If the head of the list is a boundary, it is the boundary
-  ;;  ;; preceding this command.  Get rid of it and don't count it.
-  ;;  (setq list (cdr list))))
-
+(defun undo-using-generator (generator n)
+  "Undo N change groups using a GENERATOR closure to get
+successive undo elements. Return the last association returned
+from GENERATOR or nil if the end of undo history was reached."
   (let ((arg n)
         ;; In a writable buffer, enable undoing read-only text that is
         ;; so because of text properties.
         (inhibit-read-only t)
         ;; Don't let `intangible' properties interfere with undo.
         (inhibit-point-motion-hooks t)
-        ;; We use oldlist only to check for EQ.  ++kfs
-        (oldlist buffer-undo-list)
-        (did-apply nil)
-        (next nil))
+        next-assoc)
     (while (> arg 0)
-      (while (setq next (pop list))     ;Exit inner loop at undo boundary.
+      ;; Exit this inner loop at an undo boundary, which would be
+      ;; next-assoc of (nil . nil).
+      (while (car (setq next-assoc (funcall generator)))
+        (let ((next (car next-assoc))
+              (orig-tail (cdr next-assoc))
+              (prior-undo-list buffer-undo-list))
           ;; Handle an integer by setting point to that value.
           (pcase next
             ((pred integerp) (goto-char next))
@@ -2289,21 +2310,27 @@ Return what remains of the list."
                  (apply fun-args))
                (unless (eq currbuff (current-buffer))
                  (error "Undo function switched buffer"))
-             (setq did-apply t)))
+               ;; Make sure an apply entry produces at least one undo entry,
+               ;; so the test in `undo' for continuing an undo series
+               ;; will work right.
+               (when (eq prior-undo-list buffer-undo-list)
+                 (push (list 'apply 'cdr nil) buffer-undo-list))))
             ;; Element (STRING . POS) means STRING was deleted.
             (`(,(and string (pred stringp)) . ,(and pos (pred integerp)))
              (when (let ((apos (abs pos)))
                      (or (< apos (point-min)) (> apos (point-max))))
                (error "Changes to be undone are outside visible
portion of buffer"))
-           (let (valid-marker-adjustments)
+             (let (valid-marker-adjustments
+                   ahead)
                ;; Check that marker adjustments which were recorded
                ;; with the (STRING . POS) record are still valid, ie
                ;; the markers haven't moved.  We check their validity
                ;; before reinserting the string so as we don't need to
                ;; mind marker insertion-type.
-             (while (and (markerp (car-safe (car list)))
-                         (integerp (cdr-safe (car list))))
-               (let* ((marker-adj (pop list))
+               (while (and (setq ahead (funcall generator 'peek))
+                           (markerp (car-safe (car ahead)))
+                           (integerp (cdr-safe (car ahead))))
+                 (let* ((marker-adj (car (funcall generator)))
                         (m (car marker-adj)))
                    (and (eq (marker-buffer m) (current-buffer))
                         (= pos m)
@@ -2331,16 +2358,13 @@ Return what remains of the list."
                (set-marker marker
                            (- marker offset)
                            (marker-buffer marker))))
-          (_ (error "Unrecognized entry in undo list %S" next))))
+            (_ (error "Unrecognized entry in undo list %S" next)))
+          ;; Map the new undo element to what it undid.  Not aware yet
+          ;; of cases where we want to map all new elements.
+          (unless (eq prior-undo-list buffer-undo-list)
+            (puthash buffer-undo-list orig-tail undo-redo-table))))
       (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
-    ;; will work right.
-    (if (and did-apply
-             (eq oldlist buffer-undo-list))
-        (setq buffer-undo-list
-              (cons (list 'apply 'cdr nil) buffer-undo-list))))
-  list)
+    next-assoc))

 ;; Deep copy of a list
 (defun undo-copy-list (list)
@@ -2353,16 +2377,16 @@ Return what remains of the list."
     elt))

 (defun undo-start (&optional beg end)
-  "Set `pending-undo-list' to the front of the undo list.
-The next call to `undo-more' will undo the most recently made change.
-If BEG and END are specified, then only undo elements
-that apply to text between BEG and END are used; other undo elements
-are ignored.  If BEG and END are nil, all undo elements are used."
+  "Set `pending-undo-list' to begin a run of undos.  The next
+call to `undo-more' will undo the next change group.  If BEG and
+END are specified, then only undo elements that apply to text
+between BEG and END are used; other undo elements are ignored.
+If BEG and END are nil, all undo elements are used."
   (if (eq buffer-undo-list t)
       (user-error "No undo information in this buffer"))
   (setq pending-undo-list
        (if (and beg end (not (= beg end)))
-           (undo-make-selective-list (min beg end) (max beg end))
+           (undo-make-regional-generator (min beg end) (max beg end))
          buffer-undo-list)))

 ;; The positions given in elements of the undo list are the positions
@@ -2424,30 +2448,39 @@ are ignored.  If BEG and END are nil, all undo
elements are used."
 ;; "ccaabad", as though the first "d" became detached from the
 ;; original "ddd" insertion.  This quirk is a FIXME.

-(defun undo-make-selective-list (start end)
-  "Return a list of undo elements for the region START to END.
-The elements come from `buffer-undo-list', but we keep only the
-elements inside this region, and discard those outside this
-region.  The elements' positions are adjusted so as the returned
-list can be applied to the current buffer."
+(defun undo-make-regional-generator (start end)
+  "Make a closure that will return the next undo element
+association in the region START to END each time it is called, in
+the form (ADJUSTED-ELT . ORIG-UNDO-LIST).  ADJUSTED-ELT is an
+undo element with adjusted positions and ORIG-UNDO-LIST is a cons
+of buffer-undo-list whose car is the original unadjusted undo
+element.  ADJUSTED-ELT may or may not be eq to (car
+ORIG-UNDO-LIST).
+
+The use of a closure allows for lazy adjustment of elements of
+the buffer-undo-list as needed for successive undo commands."
   (let ((ulist buffer-undo-list)
-        ;; A list of position adjusted undo elements in the region.
-        (selective-list (list nil))
+        ;; (ADJUSTED-ELT . ORIG-UNDO-LIST) associations to be returned
+        ;; from closure
+        (selective-list (list (cons nil nil)))
+        prev-assoc
         ;; A list of undo-deltas for out of region undo elements.
-        undo-deltas
-        undo-elt)
-    (while ulist
-      (setq undo-elt (car ulist))
+        undo-deltas)
+    (lambda (&optional option)
+      ;; Update selective-list with potential returns if necessary
+      (while (and ulist (not selective-list))
+        (let ((undo-elt (car ulist)))
           (cond
            ((null undo-elt)
-        ;; Don't put two nils together in the list
-        (when (car selective-list)
-          (push nil selective-list)))
+            ;; Don't put two undo boundaries, represented as (nil
+            ;; . nil), together in the list
+            (unless (equal (cons nil nil) prev-assoc)
+              (push (cons nil nil) selective-list)))
            ((and (consp undo-elt) (eq (car undo-elt) t))
             ;; This is a "was unmodified" element.  Keep it
             ;; if we have kept everything thus far.
             (when (not undo-deltas)
-          (push undo-elt selective-list)))
+              (push (cons undo-elt ulist) selective-list)))
            ;; Skip over marker adjustments, instead relying
            ;; on finding them after (TEXT . POS) elements
            ((markerp (car-safe undo-elt))
@@ -2458,19 +2491,37 @@ list can be applied to the current buffer."
               (if (undo-elt-in-region adjusted-undo-elt start end)
                   (progn
                     (setq end (+ end (cdr (undo-delta adjusted-undo-elt))))
-                (push adjusted-undo-elt selective-list)
+                    (push (cons adjusted-undo-elt ulist) selective-list)
                     ;; Keep (MARKER . ADJUSTMENT) if their (TEXT . POS) was
                     ;; kept.  primitive-undo may discard them later.
                     (when (and (stringp (car-safe adjusted-undo-elt))
                                (integerp (cdr-safe adjusted-undo-elt)))
                       (let ((list-i (cdr ulist)))
                         (while (markerp (car-safe (car list-i)))
-                      (push (pop list-i) selective-list)))))
+                          (let ((marker-adj (pop list-i)))
+                            (push (cons marker-adj marker-adj)
+                                  selective-list))))
+                      (setq selective-list (nreverse selective-list))))
                 (let ((delta (undo-delta undo-elt)))
                   (when (/= 0 (cdr delta))
-                (push delta undo-deltas)))))))
+                    (push delta undo-deltas))))))))
         (pop ulist))
+      (if (eq option 'peek)
+          (car selective-list)
+        (setq prev-assoc (pop selective-list))))))
+
+(defun undo-make-selective-list (start end)
+  "Realize a full selective undo list per
+undo-make-regional-generator."
+  (let ((selective-list nil)
+        (gen (undo-make-regional-generator start end))
+        elt)
+    (while (setq elt (funcall gen))
+      (push selective-list (car elt)))
     (nreverse selective-list)))
+(make-obsolete 'undo-make-selective-list
+               "Use undo-make-regional-generator instead."
+               "24.5")

 (defun undo-elt-in-region (undo-elt start end)
   "Determine whether UNDO-ELT falls inside the region START ... END.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
References: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
In-Reply-To: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 14 May 2014 13:33:02 +0000
Resent-Message-ID: <handler.16411.B16411.14000743351720 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 16411 <16411 <at> debbugs.gnu.org>, Stefan Monnier <monnier@HIDDEN>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.14000743351720
          (code B ref 16411); Wed, 14 May 2014 13:33:02 +0000
Received: (at 16411) by debbugs.gnu.org; 14 May 2014 13:32:15 +0000
Received: from localhost ([127.0.0.1]:34830 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WkZI6-0000Rf-5F
	for submit <at> debbugs.gnu.org; Wed, 14 May 2014 09:32:14 -0400
Received: from mail-ob0-f177.google.com ([209.85.214.177]:60596)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1WkZI1-0000RM-O8
 for 16411 <at> debbugs.gnu.org; Wed, 14 May 2014 09:32:10 -0400
Received: by mail-ob0-f177.google.com with SMTP id wp4so2044677obc.22
 for <16411 <at> debbugs.gnu.org>; Wed, 14 May 2014 06:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:date:message-id:subject:from:to:content-type;
 bh=sJkBjpRwp5rlxh0cfXH+q0eeQ4GZ32uVaNWFtV5NHZI=;
 b=pMHQ9YV3QkltB1gl5u6C5lrvTgXrsAdisLDr2HWAAvQ++anqEhxF2WYZbfiJ2KU2P9
 0XlxN32ARygC6942IAS73NFvTX/GXd7o2+kdNCTJvSjne2hM+FZhu78UoFX3eskvcMVA
 ou6b/kLXo28bOwTNT95j6TSkSS0bCfs3n2xZ7ar+9AooBmfsRo/kQwSWhoz8CRCXtZJn
 OHnHh1/1eZwtJ8fcnOBtO7pgNoNVfkAY1ZAhjCd9FwXmHIVMBfYQCZDWyogZGv1s8NuW
 SKXfwrFMfpMDeD8F1c9Yu0yITWleOvDwsNxAa+aHjJK1Xg6YXOaKa4ReG2ScQiYtUeX+
 zrkg==
MIME-Version: 1.0
X-Received: by 10.60.131.40 with SMTP id oj8mr3535069oeb.14.1400074323797;
 Wed, 14 May 2014 06:32:03 -0700 (PDT)
Received: by 10.76.6.44 with HTTP; Wed, 14 May 2014 06:32:03 -0700 (PDT)
Date: Wed, 14 May 2014 09:32:03 -0400
Message-ID: <CAFM41H1LOhCK-ukuSytRuWXr=nEzO1BjQT7ZuPzxzuBPS1zjuA@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=089e013cb828baad3304f95c3479
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e013cb828baad3304f95c3479
Content-Type: text/plain; charset=UTF-8

> 1: undo-only in region doesn't work.

+2014-05-13 Stefan Monnier <monnier@HIDDEN>
+
+ * simple.el (undo-make-selective-list): Obey undo-no-redo.

Right, this one didn't need the refactor. Thanks.

--089e013cb828baad3304f95c3479
Content-Type: text/html; charset=UTF-8

<div dir="ltr">&gt; 1: undo-only in region doesn&#39;t work.<br><br>+2014-05-13 Stefan Monnier &lt;<a href="mailto:monnier@HIDDEN">monnier@HIDDEN</a>&gt;<br>+<br>+ * simple.el (undo-make-selective-list): Obey undo-no-redo.<br>
<br>Right, this one didn&#39;t need the refactor. Thanks.<br><br></div>

--089e013cb828baad3304f95c3479--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 14 May 2014 18:08:02 +0000
Resent-Message-ID: <handler.16411.B16411.14000908295077 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.14000908295077
          (code B ref 16411); Wed, 14 May 2014 18:08:02 +0000
Received: (at 16411) by debbugs.gnu.org; 14 May 2014 18:07:09 +0000
Received: from localhost ([127.0.0.1]:35489 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wkda8-0001Jn-Fv
	for submit <at> debbugs.gnu.org; Wed, 14 May 2014 14:07:08 -0400
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:46726)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1Wkda5-0001Jc-L7
 for 16411 <at> debbugs.gnu.org; Wed, 14 May 2014 14:07:06 -0400
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
 by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s4EI72uc030830;
 Wed, 14 May 2014 14:07:03 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 4EEDD601E4; Wed, 14 May 2014 14:06:47 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwv4n0sutgh.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
Date: Wed, 14 May 2014 14:06:47 -0400
In-Reply-To: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
 (Barry OReilly's message of "Tue, 13 May 2014 11:01:32 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level: 
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0.2
X-NAI-Spam-Rules: 2 Rules triggered
	GEN_SPAM_FEATRE=0.2, RV4942=0
X-NAI-Spam-Version: 2.3.0.9378 : core <4942> : inlines <868> : streams
 <1182770> : uri <1756735>
X-Spam-Score: -2.0 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.0 (--)

>    1: undo-only in region doesn't work.

At least this should be working now.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 14 May 2014 18:46:02 +0000
Resent-Message-ID: <handler.16411.B16411.14000931492158 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.14000931492158
          (code B ref 16411); Wed, 14 May 2014 18:46:02 +0000
Received: (at 16411) by debbugs.gnu.org; 14 May 2014 18:45:49 +0000
Received: from localhost ([127.0.0.1]:34778 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WkeBY-0000Yk-Gg
	for submit <at> debbugs.gnu.org; Wed, 14 May 2014 14:45:48 -0400
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:36844)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WkeBV-0000YX-GS
 for 16411 <at> debbugs.gnu.org; Wed, 14 May 2014 14:45:47 -0400
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
 by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s4EIjir5006072;
 Wed, 14 May 2014 14:45:44 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id EC064601E4; Wed, 14 May 2014 14:45:43 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvy4y4te3h.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
Date: Wed, 14 May 2014 14:45:43 -0400
In-Reply-To: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
 (Barry OReilly's message of "Tue, 13 May 2014 11:01:32 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
	RV4942=0
X-NAI-Spam-Version: 2.3.0.9378 : core <4942> : inlines <869> : streams
 <1182802> : uri <1756765>
X-Spam-Score: -2.0 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.0 (--)

> Item 1 is the crucial one. The undo-redo-table is somewhat like
> undo-equiv-table, except that instead of mapping equal buffer states,
> it maps undo elements to what they undid.

I'm having trouble understanding it (I guess it's just that my mind
i caught in a rut, after having come up with undo-equiv-table).

> +(defvar undo-redo-table (make-hash-table :test 'eq :weakness t)
> +  "Hash table mapping undo elements created by an undo command to
> +the undo element they undid.  Specifically, the keys and values
> +are eq to cons of buffer-undo-list.  The hash table is weak so as
> +truncated undo elements can be garbage collected.")

[ Nitpick: the first line of the docstring should stand on its own.  ]
You talk here about "undo element", but AFAICT this actually points to
"a list of undo elements" (where the first element of that list is
presumably the "undo element" you mean).  Please clarify.

It's hard for me to really understand how this undo-redo-table would work
without seeing it in use.

My guess is that the "undo-only" case would skip redo entries in much
the same way as undo-in-region skips "out of bounds" entries (i.e. in
a fairly expensive way, adjusting all subsequent elements).
Combined with the fact that undo-redo-table contains entries for every
redo element rather than for every redo group, I'm slightly worried
about the resource use, but I guess that since undo-in-region is fast
enough, that won't be a problem.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 14 May 2014 19:56:02 +0000
Resent-Message-ID: <handler.16411.B16411.140009735710091 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.140009735710091
          (code B ref 16411); Wed, 14 May 2014 19:56:02 +0000
Received: (at 16411) by debbugs.gnu.org; 14 May 2014 19:55:57 +0000
Received: from localhost ([127.0.0.1]:34866 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WkfHP-0002cd-8K
	for submit <at> debbugs.gnu.org; Wed, 14 May 2014 15:55:56 -0400
Received: from chene.dit.umontreal.ca ([132.204.246.20]:44566)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WkfHK-0002cP-MI
 for 16411 <at> debbugs.gnu.org; Wed, 14 May 2014 15:55:51 -0400
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
 by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s4EJtmxU002066;
 Wed, 14 May 2014 15:55:48 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id D0598602D4; Wed, 14 May 2014 15:55:47 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvbnv0tagh.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
Date: Wed, 14 May 2014 15:55:47 -0400
In-Reply-To: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
 (Barry OReilly's message of "Tue, 13 May 2014 11:01:32 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
	RV4942=0
X-NAI-Spam-Version: 2.3.0.9378 : core <4942> : inlines <869> : streams
 <1182849> : uri <1756809>
X-Spam-Score: -2.0 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.0 (--)

> Having undo elements reference what they undid would help solve
> several issues:

>    1: undo-only in region doesn't work.
>    2: Normal undo-only after an undo in region doesn't work. I've
>       previously outlined how the solution would use the
>       undo-redo-table.
>    3: Undo in region has counter intuitive behavior as described in
>       the FIXME of simple.el describing undo in region.
>    4: Deleting X bytes, then doing Y iterations of undo and redo
>       causes undo history to grow about X*Y. To grow proportional to Y
>       should be achievable: set undo-in-progress to the in progress
>       element, and the C level undo recording to use it and
>       undo-redo-table to find the eq Lisp_String.
>    5: Undo Tree should more tightly integrate with the builtin undo
>       system. To do so, it needs sufficient information to visualize
>       the buffer-undo-list as a tree. Undo Tree has a means to
>       visualize undo in regions, so undo-equiv-table is inadequate.

IIUC this undo-redo-table business is only necessary because of
undo-in-region.  So I think we should strive to minimize the changes to
the way undo works in the absence of undo-in-region.  I understand that
the change can't be all localized in undo-in-region (because of the need
to skip "redo-in-region" during normal undo-only, basically), but we
still should try to aim in that direction.

> There are variations on how elements could reference what they undid,
> but fundamentally I think it is essential. I wish to know how you like
> the direction the patch is going as I proceed to solve some problems
> building upon it.

I think we should try to keep the "one entry per undo boundary" rather
than go for "one entry per undo element".

> The reason undo-redo-table maps at the element level, as opposed to
> the change group level, is because in the case of undo in region with
> a prefix arg, the newly created change group needs to reference
> subsets of potentially many prior change groups.

IIUC the crux of the matter is how to record the redo data for an
undo-in-region.  The way I see it, for such a "redo-in-region" group, we
indeed need to remember which elements it undid (and which ones it
skipped instead), but we could store that info as a single entry in
an undo-redo/equiv-table.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 14 May 2014 21:58:02 +0000
Resent-Message-ID: <handler.16411.B16411.140010462228549 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.140010462228549
          (code B ref 16411); Wed, 14 May 2014 21:58:02 +0000
Received: (at 16411) by debbugs.gnu.org; 14 May 2014 21:57:02 +0000
Received: from localhost ([127.0.0.1]:34935 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WkhAb-0007Q7-Bk
	for submit <at> debbugs.gnu.org; Wed, 14 May 2014 17:57:02 -0400
Received: from mail-ob0-f176.google.com ([209.85.214.176]:55044)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1WkhAY-0007Pf-O8
 for 16411 <at> debbugs.gnu.org; Wed, 14 May 2014 17:56:59 -0400
Received: by mail-ob0-f176.google.com with SMTP id wo20so225691obc.7
 for <16411 <at> debbugs.gnu.org>; Wed, 14 May 2014 14:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=AfnBxUoI0qqQu5p1JDGA1XwgXj89tGF7iN05ZIereDs=;
 b=Q37hQOeV+Paq9S/HyhranA5E/v8K7a56aazzC40nDQ5Xz/+6Z4gOOii2W4EdDPIW7v
 xsOu4kwAxehENiCsWKYygLEP+MFMGdcsgtPdpit7BBaJUp0JlIr+Qoy+FvDns71wfcPp
 7EJ7o0+1QfUbrE3WgFwswKjmQvuW0++M86Z3cIf+Wr9jHmzgCgj79M5ajQVgj77E32hm
 s9vYnuTymIzkXizN8xUr5g10AcdyiRJR4fCKuntMleXLAzU+nTRmv0qNKct0BQJ17SyH
 2X7wx/pR6IP1SlCSRDBFqUMl70om8S+ptqSsJcBqFtfFuDy3ByQPAgmCub56zTLRa/ub
 zxbQ==
MIME-Version: 1.0
X-Received: by 10.182.246.40 with SMTP id xt8mr5321392obc.76.1400104612636;
 Wed, 14 May 2014 14:56:52 -0700 (PDT)
Received: by 10.76.6.44 with HTTP; Wed, 14 May 2014 14:56:52 -0700 (PDT)
In-Reply-To: <jwvbnv0tagh.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
 <jwvbnv0tagh.fsf-monnier+emacsbugs@HIDDEN>
Date: Wed, 14 May 2014 17:56:52 -0400
Message-ID: <CAFM41H2hSaiShoNuyFsg92XjS4W_pJ65Ema2cfjDrOqxQ0u_YA@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c3224615af9504f963420c
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c3224615af9504f963420c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> You talk here about "undo element", but AFAICT this actually points
> to "a list of undo elements" (where the first element of that list
> is presumably the "undo element" you mean). Please clarify.

Yes, that's right. The first element is the "undo element" referred
to. The cons is put in the hash table to facilitate recursive lookup.

> My guess is that the "undo-only" case would skip redo entries in
> much the same way as undo-in-region skips "out of bounds" entries
> (i.e. in a fairly expensive way, adjusting all subsequent elements).

Sort of, but some of those skipped elements will cancel each other out
rather than adjust positions. See
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D16411#5 .

It's worth noting that undo-only might have to "mop up" a change group
partially undone by a prior undo in region, so a non regional
undo-only might also reference a partial change group.

> Combined with the fact that undo-redo-table contains entries for
> every redo element rather than for every redo group, I'm slightly
> worried about the resource use

I mulled over the same concern. undo-redo-table would probably be
larger than undo-equiv-table, though still a constant factor of undo
limit, IIUC. Implementing the "Y undo-redos of X" optimization is a
mitigating benefit.

I considered having the undo elements themselves reference what they
undid. Unfortunately, this approach would probably break current
undo-tree. Also, the references need to be weak, and I can only think
to do that by wrapping them in one element weak hash tables, defeating
the point.

> [ Nitpick: the first line of the docstring should stand on its own.  ]

I don't understand, I thought I formatted the docstring like others,
and did M-q it.

> IIUC this undo-redo-table business is only necessary because of
> undo-in-region. So I think we should strive to minimize the changes
> to the way undo works in the absence of undo-in-region. I understand
> that the change can't be all localized in undo-in-region (because of
> the need to skip "redo-in-region" during normal undo-only,
> basically), but we still should try to aim in that direction.

I think you're saying to not pursue the use of a closure to generate
successive undo elements as needed? I'm fine with that, but I did so
because:

  =E2=80=A2 I'm trying to prevent a performance regression of the undo-only
    command. Given the performance of undo in region with the default
    undo limit, maybe that's not a big concern.

  =E2=80=A2 I'm concerned that undo-make-selective-list's O(N**2) algorithm=
 is
    unfriendly to those who want to increase the undo limit. The
    generator allows for minimal processing of the history as needed.
    Admittedly, I have not experimented with greater undo limits.

  =E2=80=A2 I have to muck with the interfaces regardless --
    undo-make-selective-list still needs to deliver both the adjusted
    element and the orig-tail to the higher undo code.

> IIUC the crux of the matter is how to record the redo data for an
> undo-in-region. The way I see it, for such a "redo-in-region" group,
> we indeed need to remember which elements it undid (and which ones
> it skipped instead), but we could store that info as a single entry
> in an undo-redo/equiv-table.

I originally set out to do this, but making the weak references work
seemed overly tricky to me. The value stored in undo-redo-table would
need to be non weak with weak references to undo elements. I supposed
this would mean many one element weak hash tables. That seems dodgy.

--001a11c3224615af9504f963420c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; You talk here about &quot;undo element&quot;, but AFA=
ICT this actually points<br>&gt; to &quot;a list of undo elements&quot; (wh=
ere the first element of that list<br>&gt; is presumably the &quot;undo ele=
ment&quot; you mean). Please clarify.<br>
<br>Yes, that&#39;s right. The first element is the &quot;undo element&quot=
; referred<br>to. The cons is put in the hash table to facilitate recursive=
 lookup.<br><br>&gt; My guess is that the &quot;undo-only&quot; case would =
skip redo entries in<br>
&gt; much the same way as undo-in-region skips &quot;out of bounds&quot; en=
tries<br>&gt; (i.e. in a fairly expensive way, adjusting all subsequent ele=
ments).<br><br>Sort of, but some of those skipped elements will cancel each=
 other out<br>
rather than adjust positions. See<br><a href=3D"http://debbugs.gnu.org/cgi/=
bugreport.cgi?bug=3D16411#5">http://debbugs.gnu.org/cgi/bugreport.cgi?bug=
=3D16411#5</a> .<br><br>It&#39;s worth noting that undo-only might have to =
&quot;mop up&quot; a change group<br>
partially undone by a prior undo in region, so a non regional<br>undo-only =
might also reference a partial change group.<br><br>&gt; Combined with the =
fact that undo-redo-table contains entries for<br>&gt; every redo element r=
ather than for every redo group, I&#39;m slightly<br>
&gt; worried about the resource use<br><br>I mulled over the same concern. =
undo-redo-table would probably be<br>larger than undo-equiv-table, though s=
till a constant factor of undo<br>limit, IIUC. Implementing the &quot;Y und=
o-redos of X&quot; optimization is a<br>
mitigating benefit.<br><br>I considered having the undo elements themselves=
 reference what they<br>undid. Unfortunately, this approach would probably =
break current<br>undo-tree. Also, the references need to be weak, and I can=
 only think<br>
to do that by wrapping them in one element weak hash tables, defeating<br>t=
he point.<br><br>&gt; [ Nitpick: the first line of the docstring should sta=
nd on its own.=C2=A0 ]<br><br>I don&#39;t understand, I thought I formatted=
 the docstring like others,<br>
and did M-q it.<br><br>&gt; IIUC this undo-redo-table business is only nece=
ssary because of<br>&gt; undo-in-region. So I think we should strive to min=
imize the changes<br>&gt; to the way undo works in the absence of undo-in-r=
egion. I understand<br>
&gt; that the change can&#39;t be all localized in undo-in-region (because =
of<br>&gt; the need to skip &quot;redo-in-region&quot; during normal undo-o=
nly,<br>&gt; basically), but we still should try to aim in that direction.<=
br>
<br>I think you&#39;re saying to not pursue the use of a closure to generat=
e<br>successive undo elements as needed? I&#39;m fine with that, but I did =
so<br>because:<br><br>=C2=A0 =E2=80=A2 I&#39;m trying to prevent a performa=
nce regression of the undo-only<br>
=C2=A0=C2=A0=C2=A0 command. Given the performance of undo in region with th=
e default<br>=C2=A0=C2=A0=C2=A0 undo limit, maybe that&#39;s not a big conc=
ern.<br><br>=C2=A0 =E2=80=A2 I&#39;m concerned that undo-make-selective-lis=
t&#39;s O(N**2) algorithm is<br>=C2=A0=C2=A0=C2=A0 unfriendly to those who =
want to increase the undo limit. The<br>
=C2=A0=C2=A0=C2=A0 generator allows for minimal processing of the history a=
s needed.<br>=C2=A0=C2=A0=C2=A0 Admittedly, I have not experimented with gr=
eater undo limits.<br><br>=C2=A0 =E2=80=A2 I have to muck with the interfac=
es regardless --<br>=C2=A0=C2=A0=C2=A0 undo-make-selective-list still needs=
 to deliver both the adjusted<br>
=C2=A0=C2=A0=C2=A0 element and the orig-tail to the higher undo code.<br><b=
r>&gt; IIUC the crux of the matter is how to record the redo data for an<br=
>&gt; undo-in-region. The way I see it, for such a &quot;redo-in-region&quo=
t; group,<br>
&gt; we indeed need to remember which elements it undid (and which ones<br>=
&gt; it skipped instead), but we could store that info as a single entry<br=
>&gt; in an undo-redo/equiv-table.<br><br>I originally set out to do this, =
but making the weak references work<br>
seemed overly tricky to me. The value stored in undo-redo-table would<br>ne=
ed to be non weak with weak references to undo elements. I supposed<br>this=
 would mean many one element weak hash tables. That seems dodgy.<br><br>
</div>

--001a11c3224615af9504f963420c--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 May 2014 02:24:01 +0000
Resent-Message-ID: <handler.16411.B16411.140012062528450 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.140012062528450
          (code B ref 16411); Thu, 15 May 2014 02:24:01 +0000
Received: (at 16411) by debbugs.gnu.org; 15 May 2014 02:23:45 +0000
Received: from localhost ([127.0.0.1]:35046 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WklKi-0007On-Kj
	for submit <at> debbugs.gnu.org; Wed, 14 May 2014 22:23:45 -0400
Received: from chene.dit.umontreal.ca ([132.204.246.20]:43044)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WklKf-0007OZ-Eb
 for 16411 <at> debbugs.gnu.org; Wed, 14 May 2014 22:23:42 -0400
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
 by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s4F2NcaD027109;
 Wed, 14 May 2014 22:23:38 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 1CA2060366; Wed, 14 May 2014 22:23:38 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvppjfpzy7.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
 <jwvbnv0tagh.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H2hSaiShoNuyFsg92XjS4W_pJ65Ema2cfjDrOqxQ0u_YA@HIDDEN>
Date: Wed, 14 May 2014 22:23:37 -0400
In-Reply-To: <CAFM41H2hSaiShoNuyFsg92XjS4W_pJ65Ema2cfjDrOqxQ0u_YA@HIDDEN>
 (Barry OReilly's message of "Wed, 14 May 2014 17:56:52 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
	RV4942=0
X-NAI-Spam-Version: 2.3.0.9378 : core <4942> : inlines <870> : streams
 <1183088> : uri <1757034>
X-Spam-Score: -2.0 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.0 (--)

>> You talk here about "undo element", but AFAICT this actually points
>> to "a list of undo elements" (where the first element of that list
>> is presumably the "undo element" you mean). Please clarify.
> Yes, that's right.  The first element is the "undo element" referred
> to.  The cons is put in the hash table to facilitate recursive lookup.

Makes sense, but please change the docstring to make it clear.

> Implementing the "Y undo-redos of X" optimization is a
> mitigating benefit.

I've never heard anyone bump into this "Y undo-redos of X" problem, so
I don't think optimizing it is worth the trouble.  If anything should be
done with it, I think it'd be to *cut* the extra undo/redo pairs.

>> [ Nitpick: the first line of the docstring should stand on its own.  ]
> I don't understand, I thought I formatted the docstring like others,
> and did M-q it.

"Stands on its own" basically mean "doesn't end in the middle of a sentence=
".
Some commands only display the first line of a docstring.

> I think you're saying to not pursue the use of a closure to generate
> successive undo elements as needed?

Actually, I didn't really mean to say that.  I'm not completely
convinced that this generator is worthwhile (i.e. my first reaction was
to try and see how to get rid of it), but I then decided not to say
anything about it yet ;-)

>   =E2=80=A2 I'm trying to prevent a performance regression of the undo-on=
ly
>     command. Given the performance of undo in region with the default
>     undo limit, maybe that's not a big concern.

One way to avoid the performance regression is to use undo-equiv-table
for normal undo and only use undo-redo-table for undo-in-region (by
"use" I mean "add elements to", since both tables need to be looked up
when performing either undo).

>   =E2=80=A2 I'm concerned that undo-make-selective-list's O(N**2) algorit=
hm is
>     unfriendly to those who want to increase the undo limit. The
>     generator allows for minimal processing of the history as needed.
>     Admittedly, I have not experimented with greater undo limits.

The old code was no faster (neither constant-factor-wise nor
algorithmically, IIUC), and it hasn't appeared as a problem so far, so
maybe it's not worth worrying about it.

I agree that doing it lazily sounds attractive, but let's keep it
for later.  I.e. the first patch should focus on fixing "undo-only of
redo-in-region".

>   =E2=80=A2 I have to muck with the interfaces regardless --
>     undo-make-selective-list still needs to deliver both the adjusted
>     element and the orig-tail to the higher undo code.

Some change will be needed, indeed.  Backward compatibility is
important, but we should first come up with an "ideal" design, and only
then can we try and figure out which parts need to be adjusted to better
preserve compatibility.

>> IIUC the crux of the matter is how to record the redo data for an
>> undo-in-region. The way I see it, for such a "redo-in-region" group,
>> we indeed need to remember which elements it undid (and which ones
>> it skipped instead), but we could store that info as a single entry
>> in an undo-redo/equiv-table.
> I originally set out to do this, but making the weak references work
> seemed overly tricky to me.  The value stored in undo-redo-table would
> need to be non weak with weak references to undo elements.  I supposed
> this would mean many one element weak hash tables. That seems dodgy.

Hmm... that's a very good point.  Worth mentioning in a comment.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 May 2014 03:52:02 +0000
Resent-Message-ID: <handler.16411.B16411.14001258756701 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.14001258756701
          (code B ref 16411); Thu, 15 May 2014 03:52:02 +0000
Received: (at 16411) by debbugs.gnu.org; 15 May 2014 03:51:15 +0000
Received: from localhost ([127.0.0.1]:35092 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WkmhO-0001k1-8C
	for submit <at> debbugs.gnu.org; Wed, 14 May 2014 23:51:14 -0400
Received: from mail-ob0-f171.google.com ([209.85.214.171]:33564)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1WkmhM-0001ji-0r
 for 16411 <at> debbugs.gnu.org; Wed, 14 May 2014 23:51:12 -0400
Received: by mail-ob0-f171.google.com with SMTP id wn1so572111obc.16
 for <16411 <at> debbugs.gnu.org>; Wed, 14 May 2014 20:51:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=gZ9DmMc59at8puok66dZjZxhVCyC69tX6z0GpiEET4U=;
 b=vfCvF4j49ST9h2Aj7EPo2Nk9S+IrxKgNp40m74KShegEFMQZDII6otAr24aPPaSsM8
 9JdRM0zS9TtB5NJo9Lh4vtBEe+aoD1yYJ/aMRrcQwP122/yA25wti4mQUSZQKUry8/6O
 Id5kKhepRQT+hl6YwGI8NC5AD8prYfG5tQ/V5+hHwId6wFelg6W8qHtaqgVF1gNFHYnu
 O7kR/U68MhHmnJuYse87p5tqfTQRT5muHqJVMh37MKglKhdYNmjO4D5kZPVjlH4yHqik
 ch81PbirQR9PKUMc+LHQQiCGikZVbjEnDxY1gBDOePiG6DJQylTG/JehXRqOa/Gy5PPb
 lPMA==
MIME-Version: 1.0
X-Received: by 10.182.246.40 with SMTP id xt8mr60942obc.76.1400125866045; Wed,
 14 May 2014 20:51:06 -0700 (PDT)
Received: by 10.76.6.44 with HTTP; Wed, 14 May 2014 20:51:05 -0700 (PDT)
In-Reply-To: <jwvppjfpzy7.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
 <jwvbnv0tagh.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H2hSaiShoNuyFsg92XjS4W_pJ65Ema2cfjDrOqxQ0u_YA@HIDDEN>
 <jwvppjfpzy7.fsf-monnier+emacsbugs@HIDDEN>
Date: Wed, 14 May 2014 23:51:05 -0400
Message-ID: <CAFM41H0JhLL=RNcFCohG=UHArDCy__0mnKnmfTvrH=zE27aLkg@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c32246e2f4fe04f9683492
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c32246e2f4fe04f9683492
Content-Type: text/plain; charset=UTF-8

> I've never heard anyone bump into this "Y undo-redos of X" problem,
> so I don't think optimizing it is worth the trouble.

Happens to me all the time.

> If anything should be done with it, I think it'd be to *cut* the
> extra undo/redo pairs.

No complaint from me. That would change the behavior of ordinary undo
command, which you just said you don't want to change.

> I'm not completely convinced that this generator is worthwhile

Ok, I'll lose it then.

>> I originally set out to do this, but making the weak references
>> work seemed overly tricky to me. The value stored in
>> undo-redo-table would need to be non weak with weak references to
>> undo elements. I supposed this would mean many one element weak
>> hash tables. That seems dodgy.

> Hmm... that's a very good point. Worth mentioning in a comment.

You actually want me to do that? That is: wrap every referenced
element in a size 1 weak hash table. Are you sure that gives the
memory savings over the element level mapping of the undo-redo-table
in the patch?

--001a11c32246e2f4fe04f9683492
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; I&#39;ve never heard anyone bump into this &quot;Y un=
do-redos of X&quot; problem,<br>&gt; so I don&#39;t think optimizing it is =
worth the trouble.<br><br>Happens to me all the time.<br><br>&gt; If anythi=
ng should be done with it, I think it&#39;d be to *cut* the<br>
&gt; extra undo/redo pairs.<br><br>No complaint from me. That would change =
the behavior of ordinary undo<br>command, which you just said you don&#39;t=
 want to change.<br><br>&gt; I&#39;m not completely convinced that this gen=
erator is worthwhile<br>
<br>Ok, I&#39;ll lose it then.<br><br>&gt;&gt; I originally set out to do t=
his, but making the weak references<br>&gt;&gt; work seemed overly tricky t=
o me. The value stored in<br>&gt;&gt; undo-redo-table would need to be non =
weak with weak references to<br>
&gt;&gt; undo elements. I supposed this would mean many one element weak<br=
>&gt;&gt; hash tables. That seems dodgy.<br><br>&gt; Hmm... that&#39;s a ve=
ry good point. Worth mentioning in a comment.<br><br>You actually want me t=
o do that? That is: wrap every referenced<br>
element in a size 1 weak hash table. Are you sure that gives the<br>memory =
savings over the element level mapping of the undo-redo-table<br>in the pat=
ch?<br><br></div>

--001a11c32246e2f4fe04f9683492--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 May 2014 13:01:01 +0000
Resent-Message-ID: <handler.16411.B16411.14001588328909 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.14001588328909
          (code B ref 16411); Thu, 15 May 2014 13:01:01 +0000
Received: (at 16411) by debbugs.gnu.org; 15 May 2014 13:00:32 +0000
Received: from localhost ([127.0.0.1]:35476 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WkvGw-0002JZ-E0
	for submit <at> debbugs.gnu.org; Thu, 15 May 2014 09:00:31 -0400
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:41814)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WkvGt-0002JN-5C
 for 16411 <at> debbugs.gnu.org; Thu, 15 May 2014 09:00:28 -0400
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
 by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s4FD0OQ8019941;
 Thu, 15 May 2014 09:00:25 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 4DD35600DB; Thu, 15 May 2014 09:00:24 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvwqdnnrbd.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
 <jwvbnv0tagh.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H2hSaiShoNuyFsg92XjS4W_pJ65Ema2cfjDrOqxQ0u_YA@HIDDEN>
 <jwvppjfpzy7.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H0JhLL=RNcFCohG=UHArDCy__0mnKnmfTvrH=zE27aLkg@HIDDEN>
Date: Thu, 15 May 2014 09:00:24 -0400
In-Reply-To: <CAFM41H0JhLL=RNcFCohG=UHArDCy__0mnKnmfTvrH=zE27aLkg@HIDDEN>
 (Barry OReilly's message of "Wed, 14 May 2014 23:51:05 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
	RV4942=0
X-NAI-Spam-Version: 2.3.0.9378 : core <4942> : inlines <871> : streams
 <1183534> : uri <1757418>
X-Spam-Score: -2.0 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.0 (--)

>> If anything should be done with it, I think it'd be to *cut* the
>> extra undo/redo pairs.
> No complaint from me.   That would change the behavior of ordinary undo
> command,

Yes.  And I think that's what we want: as a user, having to wade through
N repetitions of redo/undo is a pain.  Those that suffer often from it
probably switched to undo-tree.

The idea of cutting the extra undo-redo pairs follows the following
principle: an undo-redo pair gives you access to 1 past buffer state,
but if the earlier undo elements already made you go through an
identical state, then this undo-redo pair is superfluous.

I'm sure this can be generalized for undo-in-region (where an undo-redo
pair may not bring you exactly to the same state, but still gives you
access to a change you've already seen earlier in the undo list), but
I'm sure you can define it more easily than I.

> which you just said you don't want to change.

So far there was no discussion of changing behavior: only fixing bugs
and changing implementation.

>> I'm not completely convinced that this generator is worthwhile
> Ok, I'll lose it then.

We may want to (re)introduce it later, tho.

>>> I originally set out to do this, but making the weak references
>>> work seemed overly tricky to me. The value stored in
>>> undo-redo-table would need to be non weak with weak references to
>>> undo elements. I supposed this would mean many one element weak
>>> hash tables. That seems dodgy.
>> Hmm... that's a very good point. Worth mentioning in a comment.
> You actually want me to do that? That is: wrap every referenced
> element in a size 1 weak hash table.

God no!  I'm saying that I agree with your justification for the design of
undo-redo-table keeping mappings for every undo-element rather than one
per undo group; but that you need to put a comment in the code
explaining why it's done this way.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Barry OReilly <gundaetiapo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 28 May 2014 18:43:01 +0000
Resent-Message-ID: <handler.16411.B16411.140130257111768 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.140130257111768
          (code B ref 16411); Wed, 28 May 2014 18:43:01 +0000
Received: (at 16411) by debbugs.gnu.org; 28 May 2014 18:42:51 +0000
Received: from localhost ([127.0.0.1]:34834 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WpioI-00033d-5K
	for submit <at> debbugs.gnu.org; Wed, 28 May 2014 14:42:51 -0400
Received: from mail-oa0-f54.google.com ([209.85.219.54]:48347)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gundaetiapo@HIDDEN>) id 1WpioB-00033D-MR
 for 16411 <at> debbugs.gnu.org; Wed, 28 May 2014 14:42:44 -0400
Received: by mail-oa0-f54.google.com with SMTP id j17so11552752oag.13
 for <16411 <at> debbugs.gnu.org>; Wed, 28 May 2014 11:42:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=MopVM+tZm9gqdGgn3tu+q2C51bvHDJgS4KjapGlJrnU=;
 b=Tx2E1SNUOtiso+/mPiMjPLbXSe4F0KkXagMzQ8UAiwizfnB84Obj8+/bhZdy8afdDW
 bzprGKJicziAR9o+FmFcvFjLMLuknbghxlUgfROxtDMdQEhvzFFXZDdbbNifgbMhtmO+
 np+cCef5FjXpNv2TeyErz13hvNtGZC3bG57Rpdzc5ef+3Wkebx8OCpTX3NdikNIPXpKz
 /HXOqw0QNvhlXD23RrguilB3NlX4GqudoZFJ9e+gmqbZlnRcaHk9gx4cE7HIGWl4/T5z
 7Yrz3EcTd69eCN4lm1Zje5BdGjmSDXZhDT493ejAmOmDd7gEjDVDt7Rx6ORGFr8x/Sgl
 U5PA==
MIME-Version: 1.0
X-Received: by 10.60.50.197 with SMTP id e5mr1848141oeo.37.1401302553700; Wed,
 28 May 2014 11:42:33 -0700 (PDT)
Received: by 10.76.6.44 with HTTP; Wed, 28 May 2014 11:42:33 -0700 (PDT)
In-Reply-To: <jwvwqdnnrbd.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
 <jwvbnv0tagh.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H2hSaiShoNuyFsg92XjS4W_pJ65Ema2cfjDrOqxQ0u_YA@HIDDEN>
 <jwvppjfpzy7.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H0JhLL=RNcFCohG=UHArDCy__0mnKnmfTvrH=zE27aLkg@HIDDEN>
 <jwvwqdnnrbd.fsf-monnier+emacsbugs@HIDDEN>
Date: Wed, 28 May 2014 14:42:33 -0400
Message-ID: <CAFM41H08EvW3nrrrGbaD3y4YbjY0D1sefPLbTzenSFFSLNLvag@HIDDEN>
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/mixed; boundary=001a11c2ed6ceff48804fa7a2cf3
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c2ed6ceff48804fa7a2cf3
Content-Type: multipart/alternative; boundary=001a11c2ed6ceff48304fa7a2cf1

--001a11c2ed6ceff48304fa7a2cf1
Content-Type: text/plain; charset=UTF-8

I have attached a patch against trunk which omits the generators,
changes the data format of pending-undo-list, and addresses other
comments. The undo-tests pass with this patch. As with the last
patch, it doesn't solve an actual bug yet, but that is
forthcoming.

Since undo-tree uses primitive-undo, I think it must remain
compatible. To do this and not duplicate code, I split individual
element logic out to an undo-primitive-elt function and moved the
look ahead at marker adjustments to undo-more. Since the latter
is recent functionality, I doubt undo-tree relies on
primitive-undo doing that.

--001a11c2ed6ceff48304fa7a2cf1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have attached a patch against trunk which omits the gene=
rators,<br>changes the data format of pending-undo-list, and addresses othe=
r<br>comments. The undo-tests pass with this patch. As with the last<br>pat=
ch, it doesn&#39;t solve an actual bug yet, but that is<br>
forthcoming.<br><br>Since undo-tree uses primitive-undo, I think it must re=
main<br>compatible. To do this and not duplicate code, I split individual<b=
r>element logic out to an undo-primitive-elt function and moved the<br>
look ahead at marker adjustments to undo-more. Since the latter<br>is recen=
t functionality, I doubt undo-tree relies on<br>primitive-undo doing that.<=
br><br></div>

--001a11c2ed6ceff48304fa7a2cf1--
--001a11c2ed6ceff48804fa7a2cf3
Content-Type: text/plain; charset=US-ASCII; name="undone-undos.diff"
Content-Disposition: attachment; filename="undone-undos.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hvqzbq6d0

ZGlmZiAtLWdpdCBhL2xpc3Avc2ltcGxlLmVsIGIvbGlzcC9zaW1wbGUuZWwKaW5kZXggYWY4ZTQ3
Yy4uOWI0N2NjYiAxMDA2NDQKLS0tIGEvbGlzcC9zaW1wbGUuZWwKKysrIGIvbGlzcC9zaW1wbGUu
ZWwKQEAgLTIwNTQsMjAgKzIwNTQsNTAgQEAgR28gdG8gdGhlIGhpc3RvcnkgZWxlbWVudCBieSB0
aGUgYWJzb2x1dGUgaGlzdG9yeSBwb3NpdGlvbiBISVNULVBPUy4iCiA7UHV0IHRoaXMgb24gQy14
IHUsIHNvIHdlIGNhbiBmb3JjZSB0aGF0IHJhdGhlciB0aGFuIEMtXyBpbnRvIHN0YXJ0dXAgbXNn
CiAoZGVmaW5lLW9ic29sZXRlLWZ1bmN0aW9uLWFsaWFzICdhZHZlcnRpc2VkLXVuZG8gJ3VuZG8g
IjIzLjIiKQogCis7OyBOb3RlOiBXZSBjb25zaWRlcmVkIGEgZGVzaWduIHdoZXJlYnkgb25lIGVu
dHJ5IGluIHRoZQorOzsgdW5kby1yZWRvLXRhYmxlIG1hcHMgYSBjaGFuZ2UgZ3JvdXAgdG8gYSBs
aXN0IG9mIHVuZG9uZSBlbGVtZW50cyBvcgorOzsgZ3JvdXBzLiAgVGhpcyBkZXNpZ24gZG9lcyBu
b3Qgd29yayBiZWNhdXNlIHRoZSB2YWx1ZSBzdG9yZWQgaW4KKzs7IHVuZG8tcmVkby10YWJsZSB3
b3VsZCBuZWVkIHRvIGJlIGEgbm9uIHdlYWsgbGlzdCB3aXRoIHdlYWsKKzs7IHJlZmVyZW5jZXMg
aW50byBidWZmZXItdW5kby1saXN0LiAgQ3VycmVudGx5IEVsaXNwIG9ubHkgZmVhdHVyZXMKKzs7
IHdlYWsgcmVmZXJlbmNlcyB3aGVuIHRoZXkgYXJlIGRpcmVjdGx5IGtleXMgb3IgdmFsdWVzIG9m
IGEgd2VhaworOzsgaGFzaCB0YWJsZSwgc28gYSBsaXN0IGNvbnRhaW5pbmcgd2VhayByZWZlcmVu
Y2VzIGlzIG5vdCBzdXBwb3J0ZWQuCisoZGVmdmFyIHVuZG8tcmVkby10YWJsZSAobWFrZS1oYXNo
LXRhYmxlIDp0ZXN0ICdlcSA6d2Vha25lc3MgdCkKKyAgIkhhc2ggdGFibGUgbWFwcGluZyB1bmRv
cyB0byB3aGF0IHRoZXkgdW5kaWQuCisKK1NwZWNpZmljYWxseSwgdGhlIGtleXMgYW5kIHZhbHVl
cyBhcmUgZXEgdG8gYSBjb25zIG9mCitidWZmZXItdW5kby1saXN0IHN1Y2ggdGhhdCB0aGUgY2Fy
IG9mIHRoZSBrZXkgaXMgYW4gdW5kbyBlbGVtZW50CithbmQgdGhlIGNhciBvZiB0aGUgdmFsdWUg
aXMgdGhlIHVuZG9uZSBlbGVtZW50LgorCitUaGUgaGFzaCB0YWJsZSBpcyB3ZWFrIHNvIGFzIHRy
dW5jYXRlZCB1bmRvIGVsZW1lbnRzIGNhbiBiZQorZ2FyYmFnZSBjb2xsZWN0ZWQuIikKIChkZWZj
b25zdCB1bmRvLWVxdWl2LXRhYmxlIChtYWtlLWhhc2gtdGFibGUgOnRlc3QgJ2VxIDp3ZWFrbmVz
cyB0KQogICAiVGFibGUgbWFwcGluZyByZWRvIHJlY29yZHMgdG8gdGhlIGNvcnJlc3BvbmRpbmcg
dW5kbyBvbmUuCiBBIHJlZG8gcmVjb3JkIGZvciB1bmRvLWluLXJlZ2lvbiBtYXBzIHRvIHQuCiBB
IHJlZG8gcmVjb3JkIGZvciBvcmRpbmFyeSB1bmRvIG1hcHMgdG8gdGhlIGZvbGxvd2luZyAoZWFy
bGllcikgdW5kby4iKQorKG1ha2Utb2Jzb2xldGUtdmFyaWFibGUKKyAndW5kby1lcXVpdi10YWJs
ZQorICJVc2UgdW5kby1yZWRvLXRhYmxlIGluc3RlYWQuICBGb3Igbm9uIHJlZ2lvbmFsIHVuZG9z
LCAoZ2V0aGFzaAorayB1bmRvLWVxdWl2LXRhYmxlKSBpcyB0aGUgc2FtZSBhcyB0YWtpbmcgKGdl
dGhhc2ggawordW5kby1yZWRvLXRhYmxlKSBhbmQgc2Nhbm5pbmcgZm9yd2FyZCBvbmUgY2hhbmdl
IGdyb3VwLiIKKyAiMjQuNSIpCiAKIChkZWZ2YXIgdW5kby1pbi1yZWdpb24gbmlsCi0gICJOb24t
bmlsIGlmIGBwZW5kaW5nLXVuZG8tbGlzdCcgaXMgbm90IGp1c3QgYSB0YWlsIG9mIGBidWZmZXIt
dW5kby1saXN0Jy4iKQorICAiTm9uLW5pbCBkdXJpbmcgYW4gdW5kbyBpbiByZWdpb24uIikKIAog
KGRlZnZhciB1bmRvLW5vLXJlZG8gbmlsCiAgICJJZiB0LCBgdW5kbycgZG9lc24ndCBnbyB0aHJv
dWdoIHJlZG8gZW50cmllcy4iKQogCiAoZGVmdmFyIHBlbmRpbmctdW5kby1saXN0IG5pbAotICAi
V2l0aGluIGEgcnVuIG9mIGNvbnNlY3V0aXZlIHVuZG8gY29tbWFuZHMsIGxpc3QgcmVtYWluaW5n
IHRvIGJlIHVuZG9uZS4KLUlmIHQsIHdlIHVuZGlkIGFsbCB0aGUgd2F5IHRvIHRoZSBlbmQgb2Yg
aXQuIikKKyAgIlRoZSBwZW5kaW5nIHVuZG8gZWxlbWVudHMgaW4gYSBydW4gb2YgY29uc2VjdXRp
dmUgdW5kbyBjb21tYW5kcy4KKworU3BlY2lmaWNhbGx5LCB0aGlzIGlzIGEgbGlzdCBvZiBhc3Nv
Y2F0aW9ucyBvZiB0aGUKK2Zvcm0gKEFESlVTVEVELUVMVCAuIE9SSUctVU5ETy1MSVNUKS4gIEFE
SlVTVEVELUVMVCBpcyBhbiB1bmRvCitlbGVtZW50IHdpdGggYWRqdXN0ZWQgcG9zaXRpb25zIGFu
ZCBPUklHLVVORE8tTElTVCBpcyBhIGNvbnMgb2YKK2J1ZmZlci11bmRvLWxpc3Qgd2hvc2UgY2Fy
IGlzIHRoZSBvcmlnaW5hbCB1bmFkanVzdGVkIHVuZG8KK2VsZW1lbnQuICBBREpVU1RFRC1FTFQg
bWF5IG9yIG1heSBub3QgYmUgZXEgdG8gKGNhcgorT1JJRy1VTkRPLUxJU1QpLgorCitJZiB0LCB0
aGVyZSBpcyBubyBtb3JlIHRvIHVuZG8uIikKIAogKGRlZnVuIHVuZG8gKCZvcHRpb25hbCBhcmcp
CiAgICJVbmRvIHNvbWUgcHJldmlvdXMgY2hhbmdlcy4KQEAgLTIxMTUsOSArMjE0NSw4IEBAIGFz
IGFuIGFyZ3VtZW50IGxpbWl0cyB1bmRvIHRvIGNoYW5nZXMgd2l0aGluIHRoZSBjdXJyZW50IHJl
Z2lvbi4iCiAgICAgICAodW5kby1tb3JlIDEpKQogICAgIDs7IElmIHdlIGdvdCB0aGlzIGZhciwg
dGhlIG5leHQgY29tbWFuZCBzaG91bGQgYmUgYSBjb25zZWN1dGl2ZSB1bmRvLgogICAgIChzZXRx
IHRoaXMtY29tbWFuZCAndW5kbykKLSAgICA7OyBDaGVjayB0byBzZWUgd2hldGhlciB3ZSdyZSBo
aXR0aW5nIGEgcmVkbyByZWNvcmQsIGFuZCBpZgotICAgIDs7IHNvLCBhc2sgdGhlIHVzZXIgd2hl
dGhlciBzaGUgd2FudHMgdG8gc2tpcCB0aGUgcmVkby91bmRvIHBhaXIuCi0gICAgKGxldCAoKGVx
dWl2IChnZXRoYXNoIHBlbmRpbmctdW5kby1saXN0IHVuZG8tZXF1aXYtdGFibGUpKSkKKyAgICA7
OyBDaGVjayB0byBzZWUgd2hldGhlciB3ZSdyZSBoaXR0aW5nIGEgcmVkbyByZWNvcmQKKyAgICAo
bGV0ICgoZXF1aXYgKGdldGhhc2ggKGNkci1zYWZlIHBlbmRpbmctdW5kby1saXN0KSB1bmRvLWVx
dWl2LXRhYmxlKSkpCiAgICAgICAob3IgKGVxIChzZWxlY3RlZC13aW5kb3cpIChtaW5pYnVmZmVy
LXdpbmRvdykpCiAJICAoc2V0cSBtZXNzYWdlIChmb3JtYXQgIiVzJXMhIgogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAoaWYgKG9yIHVuZG8tbm8tcmVkbyAobm90IGVxdWl2KSkKQEAg
LTIxMjgsNyArMjE1Nyw3IEBAIGFzIGFuIGFyZ3VtZW50IGxpbWl0cyB1bmRvIHRvIGNoYW5nZXMg
d2l0aGluIHRoZSBjdXJyZW50IHJlZ2lvbi4iCiAJOzsgdW5kby1yZWRvLXVuZG8tcmVkby0uLi4g
c28gc2tpcCB0byB0aGUgdmVyeSBsYXN0IGVxdWl2LgogCSh3aGlsZSAobGV0ICgobmV4dCAoZ2V0
aGFzaCBlcXVpdiB1bmRvLWVxdWl2LXRhYmxlKSkpCiAJCSAoaWYgbmV4dCAoc2V0cSBlcXVpdiBu
ZXh0KSkpKQotCShzZXRxIHBlbmRpbmctdW5kby1saXN0IGVxdWl2KSkpCisJKHNldHEgcGVuZGlu
Zy11bmRvLWxpc3QgKGNvbnMgKGNhciBlcXVpdikgZXF1aXYpKSkpCiAgICAgKHVuZG8tbW9yZQog
ICAgICAoaWYgKG51bWJlcnAgYXJnKQogCSAocHJlZml4LW51bWVyaWMtdmFsdWUgYXJnKQpAQCAt
MjEzOCwxOCArMjE2NywyMCBAQCBhcyBhbiBhcmd1bWVudCBsaW1pdHMgdW5kbyB0byBjaGFuZ2Vz
IHdpdGhpbiB0aGUgY3VycmVudCByZWdpb24uIgogICAgIDs7IEluIHRoZSBvcmRpbmFyeSBjYXNl
IChub3Qgd2l0aGluIGEgcmVnaW9uKSwgbWFwIHRoZSByZWRvCiAgICAgOzsgcmVjb3JkIHRvIHRo
ZSBmb2xsb3dpbmcgdW5kb3MuCiAgICAgOzsgSSBkb24ndCBrbm93IGhvdyB0byBkbyB0aGF0IGlu
IHRoZSB1bmRvLWluLXJlZ2lvbiBjYXNlLgotICAgIChsZXQgKChsaXN0IGJ1ZmZlci11bmRvLWxp
c3QpKQorICAgIChsZXQgKChsaXN0IGJ1ZmZlci11bmRvLWxpc3QpCisgICAgICAgICAgKG5ldy1l
cXVpdiAoY2RyLXNhZmUgcGVuZGluZy11bmRvLWxpc3QpKSkKICAgICAgIDs7IFN0cmlwIGFueSBs
ZWFkaW5nIHVuZG8gYm91bmRhcmllcyB0aGVyZSBtaWdodCBiZSwgbGlrZSB3ZSBkbwogICAgICAg
OzsgYWJvdmUgd2hlbiBjaGVja2luZy4KICAgICAgICh3aGlsZSAoZXEgKGNhciBsaXN0KSBuaWwp
CiAJKHNldHEgbGlzdCAoY2RyIGxpc3QpKSkKLSAgICAgIChwdXRoYXNoIGxpc3QKLSAgICAgICAg
ICAgICAgIDs7IFByZXZlbnQgaWRlbnRpdHkgbWFwcGluZy4gIFRoaXMgY2FuIGhhcHBlbiBpZgot
ICAgICAgICAgICAgICAgOzsgY29uc2VjdXRpdmUgbmlscyBhcmUgZXJyb25lb3VzbHkgaW4gdW5k
byBsaXN0LgotICAgICAgICAgICAgICAgKGlmIChvciB1bmRvLWluLXJlZ2lvbiAoZXEgbGlzdCBw
ZW5kaW5nLXVuZG8tbGlzdCkpCi0gICAgICAgICAgICAgICAgICAgdAotICAgICAgICAgICAgICAg
ICBwZW5kaW5nLXVuZG8tbGlzdCkKLQkgICAgICAgdW5kby1lcXVpdi10YWJsZSkpCisgICAgICAo
d2hlbiBuZXctZXF1aXYKKyAgICAgICAgKHB1dGhhc2ggbGlzdAorICAgICAgICAgICAgICAgICA7
OyBQcmV2ZW50IGlkZW50aXR5IG1hcHBpbmcuICBUaGlzIGNhbiBoYXBwZW4gaWYKKyAgICAgICAg
ICAgICAgICAgOzsgY29uc2VjdXRpdmUgbmlscyBhcmUgZXJyb25lb3VzbHkgaW4gdW5kbyBsaXN0
LgorICAgICAgICAgICAgICAgICAoaWYgKG9yIHVuZG8taW4tcmVnaW9uIChlcSBsaXN0IG5ldy1l
cXVpdikpCisgICAgICAgICAgICAgICAgICAgICB0CisgICAgICAgICAgICAgICAgICAgbmV3LWVx
dWl2KQorICAgICAgICAgICAgICAgICB1bmRvLWVxdWl2LXRhYmxlKSkpCiAgICAgOzsgRG9uJ3Qg
c3BlY2lmeSBhIHBvc2l0aW9uIGluIHRoZSB1bmRvIHJlY29yZCBmb3IgdGhlIHVuZG8gY29tbWFu
ZC4KICAgICA7OyBJbnN0ZWFkLCB1bmRvaW5nIHRoaXMgc2hvdWxkIG1vdmUgcG9pbnQgdG8gd2hl
cmUgdGhlIGNoYW5nZSBpcy4KICAgICAobGV0ICgodGFpbCBidWZmZXItdW5kby1saXN0KQpAQCAt
MjIwMiwxNDUgKzIyMzMsMTUyIEBAIFNvbWUgY2hhbmdlLWhvb2tzIHRlc3QgdGhpcyB2YXJpYWJs
ZSB0byBkbyBzb21ldGhpbmcgZGlmZmVyZW50LiIpCiAgICJVbmRvIGJhY2sgTiB1bmRvLWJvdW5k
YXJpZXMgYmV5b25kIHdoYXQgd2FzIGFscmVhZHkgdW5kb25lIHJlY2VudGx5LgogQ2FsbCBgdW5k
by1zdGFydCcgdG8gZ2V0IHJlYWR5IHRvIHVuZG8gcmVjZW50IGNoYW5nZXMsCiB0aGVuIGNhbGwg
YHVuZG8tbW9yZScgb25lIG9yIG1vcmUgdGltZXMgdG8gdW5kbyB0aGVtLiIKLSAgKG9yIChsaXN0
cCBwZW5kaW5nLXVuZG8tbGlzdCkKLSAgICAgICh1c2VyLWVycm9yIChjb25jYXQgIk5vIGZ1cnRo
ZXIgdW5kbyBpbmZvcm1hdGlvbiIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgKGFuZCB1bmRv
LWluLXJlZ2lvbiAiIGZvciByZWdpb24iKSkpKQotICAobGV0ICgodW5kby1pbi1wcm9ncmVzcyB0
KSkKLSAgICA7OyBOb3RlOiBUaGUgZm9sbG93aW5nLCB3aGlsZSBwdWxsaW5nIGVsZW1lbnRzIG9m
ZgotICAgIDs7IGBwZW5kaW5nLXVuZG8tbGlzdCcgd2lsbCBjYWxsIHByaW1pdGl2ZSBjaGFuZ2Ug
ZnVuY3Rpb25zIHdoaWNoCi0gICAgOzsgd2lsbCBwdXNoIG1vcmUgZWxlbWVudHMgb250byBgYnVm
ZmVyLXVuZG8tbGlzdCcuCi0gICAgKHNldHEgcGVuZGluZy11bmRvLWxpc3QgKHByaW1pdGl2ZS11
bmRvIG4gcGVuZGluZy11bmRvLWxpc3QpKQotICAgIChpZiAobnVsbCBwZW5kaW5nLXVuZG8tbGlz
dCkKLQkoc2V0cSBwZW5kaW5nLXVuZG8tbGlzdCB0KSkpKQorICAod2hlbiAoZXEgcGVuZGluZy11
bmRvLWxpc3QgdCkKKyAgICAodXNlci1lcnJvciAoY29uY2F0ICJObyBmdXJ0aGVyIHVuZG8gaW5m
b3JtYXRpb24iCisgICAgICAgICAgICAgICAgICAgICAgICAoYW5kIHVuZG8taW4tcmVnaW9uICIg
Zm9yIHJlZ2lvbiIpKSkpCisgIChsZXQgKCh1bmRvLWluLXByb2dyZXNzIHQpCisgICAgICAgIChn
cm91cCBuKQorICAgICAgICBhc3NvYykKKyAgICAod2hpbGUgKD4gZ3JvdXAgMCkKKyAgICAgICh3
aGlsZSAoY2FyIChzZXRxIGFzc29jIChwb3AgcGVuZGluZy11bmRvLWxpc3QpKSkKKyAgICAgICAg
KGxldCAoKGVsdCAoY2FyIGFzc29jKSkKKyAgICAgICAgICAgICAgKG9yaWctdGFpbCAoY2RyIGFz
c29jKSkKKyAgICAgICAgICAgICAgdmFsaWQtbWFya2VyLWFkanVzdG1lbnRzKQorICAgICAgICAg
ICh3aGVuIChhbmQgKHN0cmluZ3AgKGNhci1zYWZlIGVsdCkpCisgICAgICAgICAgICAgICAgICAg
ICAoaW50ZWdlcnAgKGNkci1zYWZlIGVsdCkpKQorICAgICAgICAgICAgOzsgQ2hlY2sgdGhhdCBt
YXJrZXIgYWRqdXN0bWVudHMgd2hpY2ggd2VyZSByZWNvcmRlZCB3aXRoCisgICAgICAgICAgICA7
OyB0aGUgKFNUUklORyAuIFBPUykgcmVjb3JkIGFyZSBzdGlsbCB2YWxpZCwgaWUgdGhlCisgICAg
ICAgICAgICA7OyBtYXJrZXJzIGhhdmVuJ3QgbW92ZWQuICBXZSBjaGVjayB0aGVpciB2YWxpZGl0
eSBiZWZvcmUKKyAgICAgICAgICAgIDs7IHJlaW5zZXJ0aW5nIHRoZSBzdHJpbmcgc28gYXMgd2Ug
ZG9uJ3QgbmVlZCB0byBtaW5kCisgICAgICAgICAgICA7OyBtYXJrZXIgaW5zZXJ0aW9uLXR5cGUu
CisgICAgICAgICAgICAod2hpbGUgKGFuZCAobWFya2VycCAoY2FyLXNhZmUgKGNhYXIgcGVuZGlu
Zy11bmRvLWxpc3QpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgIChpbnRlZ2VycCAoY2RyLXNh
ZmUgKGNhYXIgcGVuZGluZy11bmRvLWxpc3QpKSkpCisgICAgICAgICAgICAgIChsZXQqICgobWFy
a2VyLWFkaiAoY2FyIChwb3AgcGVuZGluZy11bmRvLWxpc3QpKSkKKyAgICAgICAgICAgICAgICAg
ICAgIChtIChjYXIgbWFya2VyLWFkaikpKQorICAgICAgICAgICAgICAgIChhbmQgKGVxIChtYXJr
ZXItYnVmZmVyIG0pIChjdXJyZW50LWJ1ZmZlcikpCisgICAgICAgICAgICAgICAgICAgICAoPSAo
Y2RyIGVsdCkgbSkKKyAgICAgICAgICAgICAgICAgICAgIChwdXNoIG1hcmtlci1hZGogdmFsaWQt
bWFya2VyLWFkanVzdG1lbnRzKSkpKSkKKyAgICAgICAgICAod2hlbiAobWFya2VycCAoY2FyLXNh
ZmUgZWx0KSkKKyAgICAgICAgICAgIDs7IE5vdGU6IGV2ZW4gdGhvdWdoIHRoZXNlIGVsZW1lbnRz
IGFyZSBub3QgZXhwZWN0ZWQgaW4KKyAgICAgICAgICAgIDs7IHRoZSB1bmRvIGxpc3QsIGFkanVz
dCB0aGVtIHRvIGJlIGNvbnNlcnZhdGl2ZSBmb3IgdGhlCisgICAgICAgICAgICA7OyAyNC40IHJl
bGVhc2UuICAoQnVnIzE2ODE4KQorICAgICAgICAgICAgKHdhcm4gIkVuY291bnRlcmVkICVTIGVu
dHJ5IGluIHVuZG8gbGlzdCB3aXRoIG5vIG1hdGNoaW5nIChURVhUIC4gUE9TKSBlbnRyeSIKKyAg
ICAgICAgICAgICAgICAgIGVsdCkpCisgICAgICAgICAgOzsgTm90ZTogVGhlIGZvbGxvd2luZyBj
aGFuZ2VzIHRoZSBidWZmZXIsIGFuZCBzbyBjYWxscworICAgICAgICAgIDs7IHByaW1pdGl2ZSBj
aGFuZ2UgZnVuY3Rpb25zIHRoYXQgcHVzaCBtb3JlIGVsZW1lbnRzIG9udG8KKyAgICAgICAgICA7
OyBgYnVmZmVyLXVuZG8tbGlzdCcuCisgICAgICAgICAgKHdoZW4gKHVuZG8tcHJpbWl0aXZlLWVs
dCBlbHQpCisgICAgICAgICAgICA7OyBNYXAgdGhlIG5ldyB1bmRvIGVsZW1lbnQgdG8gd2hhdCBp
dCB1bmRpZC4gIE5vdCBhd2FyZQorICAgICAgICAgICAgOzsgeWV0IG9mIGNhc2VzIHdoZXJlIHdl
IHdhbnQgdG8gbWFwIGFsbCBuZXcgZWxlbWVudHMuCisgICAgICAgICAgICAocHV0aGFzaCBidWZm
ZXItdW5kby1saXN0IG9yaWctdGFpbCB1bmRvLXJlZG8tdGFibGUpKQorICAgICAgICAgIDs7IEFk
anVzdCB0aGUgdmFsaWQgbWFya2VyIGFkanVzdG1lbnRzCisgICAgICAgICAgKGRvbGlzdCAoYWRq
IHZhbGlkLW1hcmtlci1hZGp1c3RtZW50cykKKyAgICAgICAgICAgICh1bmRvLXByaW1pdGl2ZS1l
bHQgYWRqKSkpKQorICAgICAgKHNldHEgZ3JvdXAgKDEtIGdyb3VwKSkpCisgICAgOzsgUmVhY2hl
ZCB0aGUgZW5kIG9mIHVuZG8gaGlzdG9yeQorICAgICh1bmxlc3MgcGVuZGluZy11bmRvLWxpc3Qg
KHNldHEgcGVuZGluZy11bmRvLWxpc3QgdCkpKSkKIAogKGRlZnVuIHByaW1pdGl2ZS11bmRvIChu
IGxpc3QpCi0gICJVbmRvIE4gcmVjb3JkcyBmcm9tIHRoZSBmcm9udCBvZiB0aGUgbGlzdCBMSVNU
LgorICAiVW5kbyBOIGNoYW5nZSBncm91cHMgZnJvbSB0aGUgZnJvbnQgb2YgdGhlIGxpc3QgTElT
VC4KIFJldHVybiB3aGF0IHJlbWFpbnMgb2YgdGhlIGxpc3QuIgorICAobGV0ICgoYXJnIG4pCisg
ICAgICAgIChuZXh0IG5pbCkpCisgICAgKHdoaWxlICg+IGFyZyAwKQorICAgICAgKHdoaWxlIChz
ZXRxIG5leHQgKHBvcCBsaXN0KSkgICAgIDtFeGl0IGlubmVyIGxvb3AgYXQgdW5kbyBib3VuZGFy
eS4KKyAgICAgICAgKHVuZG8tcHJpbWl0aXZlLWVsdCBuZXh0KSkKKyAgICAgIChzZXRxIGFyZyAo
MS0gYXJnKSkpKSkKIAotICA7OyBUaGlzIGlzIGEgZ29vZCBmZWF0dXJlLCBidXQgd291bGQgbWFr
ZSB1bmRvLXN0YXJ0Ci0gIDs7IHVuYWJsZSB0byBkbyB3aGF0IGlzIGV4cGVjdGVkLgotICA7Oyh3
aGVuIChudWxsIChjYXIgKGxpc3QpKSkKLSAgOzsgIDs7IElmIHRoZSBoZWFkIG9mIHRoZSBsaXN0
IGlzIGEgYm91bmRhcnksIGl0IGlzIHRoZSBib3VuZGFyeQotICA7OyAgOzsgcHJlY2VkaW5nIHRo
aXMgY29tbWFuZC4gIEdldCByaWQgb2YgaXQgYW5kIGRvbid0IGNvdW50IGl0LgotICA7OyAgKHNl
dHEgbGlzdCAoY2RyIGxpc3QpKSkpCisoZGVmdW4gdW5kby1wcmltaXRpdmUtZWx0IChuZXh0KQor
ICAiVW5kbyB0aGUgZWxlbWVudCBORVhUIGFuZCByZXR1cm4gbm9uIG5pbCBpZiBjaGFuZ2VzIHdl
cmUgbWFkZS4KIAotICAobGV0ICgoYXJnIG4pCi0gICAgICAgIDs7IEluIGEgd3JpdGFibGUgYnVm
ZmVyLCBlbmFibGUgdW5kb2luZyByZWFkLW9ubHkgdGV4dCB0aGF0IGlzCitORVhUIGlzIG9uZSBv
ZiB0aGUgdmFsaWQgZm9ybXMgZG9jdW1lbnRlZCBpbiB0aGUgVW5kbyBzZWN0aW9uIG9mCit0aGUg
RWxpc3AgbWFudWFsLiIKKyAgKGxldCAoOzsgSW4gYSB3cml0YWJsZSBidWZmZXIsIGVuYWJsZSB1
bmRvaW5nIHJlYWQtb25seSB0ZXh0IHRoYXQgaXMKICAgICAgICAgOzsgc28gYmVjYXVzZSBvZiB0
ZXh0IHByb3BlcnRpZXMuCiAgICAgICAgIChpbmhpYml0LXJlYWQtb25seSB0KQogICAgICAgICA7
OyBEb24ndCBsZXQgYGludGFuZ2libGUnIHByb3BlcnRpZXMgaW50ZXJmZXJlIHdpdGggdW5kby4K
ICAgICAgICAgKGluaGliaXQtcG9pbnQtbW90aW9uLWhvb2tzIHQpCiAgICAgICAgIDs7IFdlIHVz
ZSBvbGRsaXN0IG9ubHkgdG8gY2hlY2sgZm9yIEVRLiAgKytrZnMKLSAgICAgICAgKG9sZGxpc3Qg
YnVmZmVyLXVuZG8tbGlzdCkKLSAgICAgICAgKGRpZC1hcHBseSBuaWwpCi0gICAgICAgIChuZXh0
IG5pbCkpCi0gICAgKHdoaWxlICg+IGFyZyAwKQotICAgICAgKHdoaWxlIChzZXRxIG5leHQgKHBv
cCBsaXN0KSkgICAgIDtFeGl0IGlubmVyIGxvb3AgYXQgdW5kbyBib3VuZGFyeS4KLSAgICAgICAg
OzsgSGFuZGxlIGFuIGludGVnZXIgYnkgc2V0dGluZyBwb2ludCB0byB0aGF0IHZhbHVlLgotICAg
ICAgICAocGNhc2UgbmV4dAotICAgICAgICAgICgocHJlZCBpbnRlZ2VycCkgKGdvdG8tY2hhciBu
ZXh0KSkKLSAgICAgICAgICA7OyBFbGVtZW50ICh0IC4gVElNRSkgcmVjb3JkcyBwcmV2aW91cyBt
b2R0aW1lLgotICAgICAgICAgIDs7IFByZXNlcnZlIGFueSBmbGFnIG9mIE5PTkVYSVNURU5UX01P
RFRJTUVfTlNFQ1Mgb3IKLSAgICAgICAgICA7OyBVTktOT1dOX01PRFRJTUVfTlNFQ1MuCi0gICAg
ICAgICAgKGAodCAuICx0aW1lKQotICAgICAgICAgICA7OyBJZiB0aGlzIHJlY29yZHMgYW4gb2Jz
b2xldGUgc2F2ZQotICAgICAgICAgICA7OyAobm90IG1hdGNoaW5nIHRoZSBhY3R1YWwgZGlzayBm
aWxlKQotICAgICAgICAgICA7OyB0aGVuIGRvbid0IG1hcmsgdW5tb2RpZmllZC4KLSAgICAgICAg
ICAgKHdoZW4gKG9yIChlcXVhbCB0aW1lICh2aXNpdGVkLWZpbGUtbW9kdGltZSkpCi0gICAgICAg
ICAgICAgICAgICAgICAoYW5kIChjb25zcCB0aW1lKQotICAgICAgICAgICAgICAgICAgICAgICAg
ICAoZXF1YWwgKGxpc3QgKGNhciB0aW1lKSAoY2RyIHRpbWUpKQotICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgKHZpc2l0ZWQtZmlsZS1tb2R0aW1lKSkpKQotICAgICAgICAgICAgICh3
aGVuIChmYm91bmRwICd1bmxvY2stYnVmZmVyKQotICAgICAgICAgICAgICAgKHVubG9jay1idWZm
ZXIpKQotICAgICAgICAgICAgIChzZXQtYnVmZmVyLW1vZGlmaWVkLXAgbmlsKSkpCi0gICAgICAg
ICAgOzsgRWxlbWVudCAobmlsIFBST1AgVkFMIEJFRyAuIEVORCkgaXMgcHJvcGVydHkgY2hhbmdl
LgotICAgICAgICAgIChgKG5pbCAuICwob3IgYCgscHJvcCAsdmFsICxiZWcgLiAsZW5kKSBwY2Fz
ZS0tZG9udGNhcmUpKQotICAgICAgICAgICAod2hlbiAob3IgKD4gKHBvaW50LW1pbikgYmVnKSAo
PCAocG9pbnQtbWF4KSBlbmQpKQotICAgICAgICAgICAgIChlcnJvciAiQ2hhbmdlcyB0byBiZSB1
bmRvbmUgYXJlIG91dHNpZGUgdmlzaWJsZSBwb3J0aW9uIG9mIGJ1ZmZlciIpKQotICAgICAgICAg
ICAocHV0LXRleHQtcHJvcGVydHkgYmVnIGVuZCBwcm9wIHZhbCkpCi0gICAgICAgICAgOzsgRWxl
bWVudCAoQkVHIC4gRU5EKSBtZWFucyByYW5nZSB3YXMgaW5zZXJ0ZWQuCi0gICAgICAgICAgKGAo
LChhbmQgYmVnIChwcmVkIGludGVnZXJwKSkgLiAsKGFuZCBlbmQgKHByZWQgaW50ZWdlcnApKSkK
LSAgICAgICAgICAgOzsgKGFuZCBgKCxiZWcgLiAsZW5kKSBgKCwocHJlZCBpbnRlZ2VycCkgLiAs
KHByZWQgaW50ZWdlcnApKSkKLSAgICAgICAgICAgOzsgSWRlYWxseTogYCgsKHByZWQgaW50ZWdl
cnAgYmVnKSAuICwocHJlZCBpbnRlZ2VycCBlbmQpKQotICAgICAgICAgICAod2hlbiAob3IgKD4g
KHBvaW50LW1pbikgYmVnKSAoPCAocG9pbnQtbWF4KSBlbmQpKQotICAgICAgICAgICAgIChlcnJv
ciAiQ2hhbmdlcyB0byBiZSB1bmRvbmUgYXJlIG91dHNpZGUgdmlzaWJsZSBwb3J0aW9uIG9mIGJ1
ZmZlciIpKQotICAgICAgICAgICA7OyBTZXQgcG9pbnQgZmlyc3QgdGhpbmcsIHNvIHRoYXQgdW5k
b2luZyB0aGlzIHVuZG8KLSAgICAgICAgICAgOzsgZG9lcyBub3Qgc2VuZCBwb2ludCBiYWNrIHRv
IHdoZXJlIGl0IGlzIG5vdy4KLSAgICAgICAgICAgKGdvdG8tY2hhciBiZWcpCi0gICAgICAgICAg
IChkZWxldGUtcmVnaW9uIGJlZyBlbmQpKQotICAgICAgICAgIDs7IEVsZW1lbnQgKGFwcGx5IEZV
TiAuIEFSR1MpIG1lYW5zIGNhbGwgRlVOIHRvIHVuZG8uCi0gICAgICAgICAgKGAoYXBwbHkgLiAs
ZnVuLWFyZ3MpCi0gICAgICAgICAgIChsZXQgKChjdXJyYnVmZiAoY3VycmVudC1idWZmZXIpKSkK
LSAgICAgICAgICAgICAoaWYgKGludGVnZXJwIChjYXIgZnVuLWFyZ3MpKQotICAgICAgICAgICAg
ICAgICA7OyBMb25nIGZvcm1hdDogKGFwcGx5IERFTFRBIFNUQVJUIEVORCBGVU4gLiBBUkdTKS4K
LSAgICAgICAgICAgICAgICAgKHBjYXNlLWxldCogKChgKCxkZWx0YSAsc3RhcnQgLGVuZCAsZnVu
IC4gLGFyZ3MpIGZ1bi1hcmdzKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0YXJ0
LW1hcmsgKGNvcHktbWFya2VyIHN0YXJ0IG5pbCkpCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAoZW5kLW1hcmsgKGNvcHktbWFya2VyIGVuZCB0KSkpCi0gICAgICAgICAgICAgICAgICAg
KHdoZW4gKG9yICg+IChwb2ludC1taW4pIHN0YXJ0KSAoPCAocG9pbnQtbWF4KSBlbmQpKQotICAg
ICAgICAgICAgICAgICAgICAgKGVycm9yICJDaGFuZ2VzIHRvIGJlIHVuZG9uZSBhcmUgb3V0c2lk
ZSB2aXNpYmxlIHBvcnRpb24gb2YgYnVmZmVyIikpCi0gICAgICAgICAgICAgICAgICAgKGFwcGx5
IGZ1biBhcmdzKSA7OyBVc2UgYHNhdmUtY3VycmVudC1idWZmZXInPwotICAgICAgICAgICAgICAg
ICAgIDs7IENoZWNrIHRoYXQgdGhlIGZ1bmN0aW9uIGRpZCB3aGF0IHRoZSBlbnRyeQotICAgICAg
ICAgICAgICAgICAgIDs7IHNhaWQgaXQgd291bGQgZG8uCi0gICAgICAgICAgICAgICAgICAgKHVu
bGVzcyAoYW5kICg9IHN0YXJ0IHN0YXJ0LW1hcmspCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICg9ICgrIGRlbHRhIGVuZCkgZW5kLW1hcmspKQotICAgICAgICAgICAgICAgICAgICAg
KGVycm9yICJDaGFuZ2VzIHRvIGJlIHVuZG9uZSBieSBmdW5jdGlvbiBkaWZmZXJlbnQgdGhhbiBh
bm5vdW5jZWQiKSkKLSAgICAgICAgICAgICAgICAgICAoc2V0LW1hcmtlciBzdGFydC1tYXJrIG5p
bCkKLSAgICAgICAgICAgICAgICAgICAoc2V0LW1hcmtlciBlbmQtbWFyayBuaWwpKQotICAgICAg
ICAgICAgICAgKGFwcGx5IGZ1bi1hcmdzKSkKLSAgICAgICAgICAgICAodW5sZXNzIChlcSBjdXJy
YnVmZiAoY3VycmVudC1idWZmZXIpKQotICAgICAgICAgICAgICAgKGVycm9yICJVbmRvIGZ1bmN0
aW9uIHN3aXRjaGVkIGJ1ZmZlciIpKQotICAgICAgICAgICAgIChzZXRxIGRpZC1hcHBseSB0KSkp
Ci0gICAgICAgICAgOzsgRWxlbWVudCAoU1RSSU5HIC4gUE9TKSBtZWFucyBTVFJJTkcgd2FzIGRl
bGV0ZWQuCi0gICAgICAgICAgKGAoLChhbmQgc3RyaW5nIChwcmVkIHN0cmluZ3ApKSAuICwoYW5k
IHBvcyAocHJlZCBpbnRlZ2VycCkpKQotICAgICAgICAgICAod2hlbiAobGV0ICgoYXBvcyAoYWJz
IHBvcykpKQotICAgICAgICAgICAgICAgICAgIChvciAoPCBhcG9zIChwb2ludC1taW4pKSAoPiBh
cG9zIChwb2ludC1tYXgpKSkpCi0gICAgICAgICAgICAgKGVycm9yICJDaGFuZ2VzIHRvIGJlIHVu
ZG9uZSBhcmUgb3V0c2lkZSB2aXNpYmxlIHBvcnRpb24gb2YgYnVmZmVyIikpCi0gICAgICAgICAg
IChsZXQgKHZhbGlkLW1hcmtlci1hZGp1c3RtZW50cykKLSAgICAgICAgICAgICA7OyBDaGVjayB0
aGF0IG1hcmtlciBhZGp1c3RtZW50cyB3aGljaCB3ZXJlIHJlY29yZGVkCi0gICAgICAgICAgICAg
Ozsgd2l0aCB0aGUgKFNUUklORyAuIFBPUykgcmVjb3JkIGFyZSBzdGlsbCB2YWxpZCwgaWUKLSAg
ICAgICAgICAgICA7OyB0aGUgbWFya2VycyBoYXZlbid0IG1vdmVkLiAgV2UgY2hlY2sgdGhlaXIg
dmFsaWRpdHkKLSAgICAgICAgICAgICA7OyBiZWZvcmUgcmVpbnNlcnRpbmcgdGhlIHN0cmluZyBz
byBhcyB3ZSBkb24ndCBuZWVkIHRvCi0gICAgICAgICAgICAgOzsgbWluZCBtYXJrZXIgaW5zZXJ0
aW9uLXR5cGUuCi0gICAgICAgICAgICAgKHdoaWxlIChhbmQgKG1hcmtlcnAgKGNhci1zYWZlIChj
YXIgbGlzdCkpKQotICAgICAgICAgICAgICAgICAgICAgICAgIChpbnRlZ2VycCAoY2RyLXNhZmUg
KGNhciBsaXN0KSkpKQotICAgICAgICAgICAgICAgKGxldCogKChtYXJrZXItYWRqIChwb3AgbGlz
dCkpCi0gICAgICAgICAgICAgICAgICAgICAgKG0gKGNhciBtYXJrZXItYWRqKSkpCi0gICAgICAg
ICAgICAgICAgIChhbmQgKGVxIChtYXJrZXItYnVmZmVyIG0pIChjdXJyZW50LWJ1ZmZlcikpCi0g
ICAgICAgICAgICAgICAgICAgICAgKD0gcG9zIG0pCi0gICAgICAgICAgICAgICAgICAgICAgKHB1
c2ggbWFya2VyLWFkaiB2YWxpZC1tYXJrZXItYWRqdXN0bWVudHMpKSkpCi0gICAgICAgICAgICAg
OzsgSW5zZXJ0IHN0cmluZyBhbmQgYWRqdXN0IHBvaW50Ci0gICAgICAgICAgICAgKGlmICg8IHBv
cyAwKQotICAgICAgICAgICAgICAgICAocHJvZ24KLSAgICAgICAgICAgICAgICAgICAoZ290by1j
aGFyICgtIHBvcykpCi0gICAgICAgICAgICAgICAgICAgKGluc2VydCBzdHJpbmcpKQotICAgICAg
ICAgICAgICAgKGdvdG8tY2hhciBwb3MpCi0gICAgICAgICAgICAgICAoaW5zZXJ0IHN0cmluZykK
LSAgICAgICAgICAgICAgIChnb3RvLWNoYXIgcG9zKSkKLSAgICAgICAgICAgICA7OyBBZGp1c3Qg
dGhlIHZhbGlkIG1hcmtlciBhZGp1c3RtZW50cwotICAgICAgICAgICAgIChkb2xpc3QgKGFkaiB2
YWxpZC1tYXJrZXItYWRqdXN0bWVudHMpCi0gICAgICAgICAgICAgICAoc2V0LW1hcmtlciAoY2Fy
IGFkaikKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICgtIChjYXIgYWRqKSAoY2RyIGFkaikp
KSkpKQotICAgICAgICAgIDs7IChNQVJLRVIgLiBPRkZTRVQpIG1lYW5zIGEgbWFya2VyIE1BUktF
UiB3YXMgYWRqdXN0ZWQgYnkgT0ZGU0VULgotICAgICAgICAgIChgKCwoYW5kIG1hcmtlciAocHJl
ZCBtYXJrZXJwKSkgLiAsKGFuZCBvZmZzZXQgKHByZWQgaW50ZWdlcnApKSkKLSAgICAgICAgICAg
KHdhcm4gIkVuY291bnRlcmVkICVTIGVudHJ5IGluIHVuZG8gbGlzdCB3aXRoIG5vIG1hdGNoaW5n
IChURVhUIC4gUE9TKSBlbnRyeSIKLSAgICAgICAgICAgICAgICAgbmV4dCkKLSAgICAgICAgICAg
OzsgRXZlbiB0aG91Z2ggdGhlc2UgZWxlbWVudHMgYXJlIG5vdCBleHBlY3RlZCBpbiB0aGUgdW5k
bwotICAgICAgICAgICA7OyBsaXN0LCBhZGp1c3QgdGhlbSB0byBiZSBjb25zZXJ2YXRpdmUgZm9y
IHRoZSAyNC40Ci0gICAgICAgICAgIDs7IHJlbGVhc2UuICAoQnVnIzE2ODE4KQotICAgICAgICAg
ICAod2hlbiAobWFya2VyLWJ1ZmZlciBtYXJrZXIpCi0gICAgICAgICAgICAgKHNldC1tYXJrZXIg
bWFya2VyCi0gICAgICAgICAgICAgICAgICAgICAgICAgKC0gbWFya2VyIG9mZnNldCkKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAobWFya2VyLWJ1ZmZlciBtYXJrZXIpKSkpCi0gICAgICAgICAg
KF8gKGVycm9yICJVbnJlY29nbml6ZWQgZW50cnkgaW4gdW5kbyBsaXN0ICVTIiBuZXh0KSkpKQot
ICAgICAgKHNldHEgYXJnICgxLSBhcmcpKSkKLSAgICA7OyBNYWtlIHN1cmUgYW4gYXBwbHkgZW50
cnkgcHJvZHVjZXMgYXQgbGVhc3Qgb25lIHVuZG8gZW50cnksCi0gICAgOzsgc28gdGhlIHRlc3Qg
aW4gYHVuZG8nIGZvciBjb250aW51aW5nIGFuIHVuZG8gc2VyaWVzCi0gICAgOzsgd2lsbCB3b3Jr
IHJpZ2h0LgotICAgIChpZiAoYW5kIGRpZC1hcHBseQotICAgICAgICAgICAgIChlcSBvbGRsaXN0
IGJ1ZmZlci11bmRvLWxpc3QpKQotICAgICAgICAoc2V0cSBidWZmZXItdW5kby1saXN0Ci0gICAg
ICAgICAgICAgIChjb25zIChsaXN0ICdhcHBseSAnY2RyIG5pbCkgYnVmZmVyLXVuZG8tbGlzdCkp
KSkKLSAgbGlzdCkKKyAgICAgICAgKG9sZGxpc3QgYnVmZmVyLXVuZG8tbGlzdCkpCisgICAgOzsg
SGFuZGxlIGFuIGludGVnZXIgYnkgc2V0dGluZyBwb2ludCB0byB0aGF0IHZhbHVlLgorICAgIChw
Y2FzZSBuZXh0CisgICAgICAoKHByZWQgaW50ZWdlcnApIChnb3RvLWNoYXIgbmV4dCkpCisgICAg
ICA7OyBFbGVtZW50ICh0IC4gVElNRSkgcmVjb3JkcyBwcmV2aW91cyBtb2R0aW1lLgorICAgICAg
OzsgUHJlc2VydmUgYW55IGZsYWcgb2YgTk9ORVhJU1RFTlRfTU9EVElNRV9OU0VDUyBvcgorICAg
ICAgOzsgVU5LTk9XTl9NT0RUSU1FX05TRUNTLgorICAgICAgKGAodCAuICx0aW1lKQorICAgICAg
IDs7IElmIHRoaXMgcmVjb3JkcyBhbiBvYnNvbGV0ZSBzYXZlCisgICAgICAgOzsgKG5vdCBtYXRj
aGluZyB0aGUgYWN0dWFsIGRpc2sgZmlsZSkKKyAgICAgICA7OyB0aGVuIGRvbid0IG1hcmsgdW5t
b2RpZmllZC4KKyAgICAgICAod2hlbiAob3IgKGVxdWFsIHRpbWUgKHZpc2l0ZWQtZmlsZS1tb2R0
aW1lKSkKKyAgICAgICAgICAgICAgICAgKGFuZCAoY29uc3AgdGltZSkKKyAgICAgICAgICAgICAg
ICAgICAgICAoZXF1YWwgKGxpc3QgKGNhciB0aW1lKSAoY2RyIHRpbWUpKQorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAodmlzaXRlZC1maWxlLW1vZHRpbWUpKSkpCisgICAgICAgICAod2hl
biAoZmJvdW5kcCAndW5sb2NrLWJ1ZmZlcikKKyAgICAgICAgICAgKHVubG9jay1idWZmZXIpKQor
ICAgICAgICAgKHNldC1idWZmZXItbW9kaWZpZWQtcCBuaWwpKSkKKyAgICAgIDs7IEVsZW1lbnQg
KG5pbCBQUk9QIFZBTCBCRUcgLiBFTkQpIGlzIHByb3BlcnR5IGNoYW5nZS4KKyAgICAgIChgKG5p
bCAuICwob3IgYCgscHJvcCAsdmFsICxiZWcgLiAsZW5kKSBwY2FzZS0tZG9udGNhcmUpKQorICAg
ICAgICh3aGVuIChvciAoPiAocG9pbnQtbWluKSBiZWcpICg8IChwb2ludC1tYXgpIGVuZCkpCisg
ICAgICAgICAoZXJyb3IgIkNoYW5nZXMgdG8gYmUgdW5kb25lIGFyZSBvdXRzaWRlIHZpc2libGUg
cG9ydGlvbiBvZiBidWZmZXIiKSkKKyAgICAgICAocHV0LXRleHQtcHJvcGVydHkgYmVnIGVuZCBw
cm9wIHZhbCkpCisgICAgICA7OyBFbGVtZW50IChCRUcgLiBFTkQpIG1lYW5zIHJhbmdlIHdhcyBp
bnNlcnRlZC4KKyAgICAgIChgKCwoYW5kIGJlZyAocHJlZCBpbnRlZ2VycCkpIC4gLChhbmQgZW5k
IChwcmVkIGludGVnZXJwKSkpCisgICAgICAgOzsgKGFuZCBgKCxiZWcgLiAsZW5kKSBgKCwocHJl
ZCBpbnRlZ2VycCkgLiAsKHByZWQgaW50ZWdlcnApKSkKKyAgICAgICA7OyBJZGVhbGx5OiBgKCwo
cHJlZCBpbnRlZ2VycCBiZWcpIC4gLChwcmVkIGludGVnZXJwIGVuZCkpCisgICAgICAgKHdoZW4g
KG9yICg+IChwb2ludC1taW4pIGJlZykgKDwgKHBvaW50LW1heCkgZW5kKSkKKyAgICAgICAgIChl
cnJvciAiQ2hhbmdlcyB0byBiZSB1bmRvbmUgYXJlIG91dHNpZGUgdmlzaWJsZSBwb3J0aW9uIG9m
IGJ1ZmZlciIpKQorICAgICAgIDs7IFNldCBwb2ludCBmaXJzdCB0aGluZywgc28gdGhhdCB1bmRv
aW5nIHRoaXMgdW5kbworICAgICAgIDs7IGRvZXMgbm90IHNlbmQgcG9pbnQgYmFjayB0byB3aGVy
ZSBpdCBpcyBub3cuCisgICAgICAgKGdvdG8tY2hhciBiZWcpCisgICAgICAgKGRlbGV0ZS1yZWdp
b24gYmVnIGVuZCkpCisgICAgICA7OyBFbGVtZW50IChhcHBseSBGVU4gLiBBUkdTKSBtZWFucyBj
YWxsIEZVTiB0byB1bmRvLgorICAgICAgKGAoYXBwbHkgLiAsZnVuLWFyZ3MpCisgICAgICAgKGxl
dCAoKGN1cnJidWZmIChjdXJyZW50LWJ1ZmZlcikpKQorICAgICAgICAgKGlmIChpbnRlZ2VycCAo
Y2FyIGZ1bi1hcmdzKSkKKyAgICAgICAgICAgICA7OyBMb25nIGZvcm1hdDogKGFwcGx5IERFTFRB
IFNUQVJUIEVORCBGVU4gLiBBUkdTKS4KKyAgICAgICAgICAgICAocGNhc2UtbGV0KiAoKGAoLGRl
bHRhICxzdGFydCAsZW5kICxmdW4gLiAsYXJncykgZnVuLWFyZ3MpCisgICAgICAgICAgICAgICAg
ICAgICAgICAgIChzdGFydC1tYXJrIChjb3B5LW1hcmtlciBzdGFydCBuaWwpKQorICAgICAgICAg
ICAgICAgICAgICAgICAgICAoZW5kLW1hcmsgKGNvcHktbWFya2VyIGVuZCB0KSkpCisgICAgICAg
ICAgICAgICAod2hlbiAob3IgKD4gKHBvaW50LW1pbikgc3RhcnQpICg8IChwb2ludC1tYXgpIGVu
ZCkpCisgICAgICAgICAgICAgICAgIChlcnJvciAiQ2hhbmdlcyB0byBiZSB1bmRvbmUgYXJlIG91
dHNpZGUgdmlzaWJsZSBwb3J0aW9uIG9mIGJ1ZmZlciIpKQorICAgICAgICAgICAgICAgKGFwcGx5
IGZ1biBhcmdzKSA7OyBVc2UgYHNhdmUtY3VycmVudC1idWZmZXInPworICAgICAgICAgICAgICAg
OzsgQ2hlY2sgdGhhdCB0aGUgZnVuY3Rpb24gZGlkIHdoYXQgdGhlIGVudHJ5CisgICAgICAgICAg
ICAgICA7OyBzYWlkIGl0IHdvdWxkIGRvLgorICAgICAgICAgICAgICAgKHVubGVzcyAoYW5kICg9
IHN0YXJ0IHN0YXJ0LW1hcmspCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgKD0gKCsgZGVs
dGEgZW5kKSBlbmQtbWFyaykpCisgICAgICAgICAgICAgICAgIChlcnJvciAiQ2hhbmdlcyB0byBi
ZSB1bmRvbmUgYnkgZnVuY3Rpb24gZGlmZmVyZW50IHRoYW4gYW5ub3VuY2VkIikpCisgICAgICAg
ICAgICAgICAoc2V0LW1hcmtlciBzdGFydC1tYXJrIG5pbCkKKyAgICAgICAgICAgICAgIChzZXQt
bWFya2VyIGVuZC1tYXJrIG5pbCkpCisgICAgICAgICAgIChhcHBseSBmdW4tYXJncykpCisgICAg
ICAgICAodW5sZXNzIChlcSBjdXJyYnVmZiAoY3VycmVudC1idWZmZXIpKQorICAgICAgICAgICAo
ZXJyb3IgIlVuZG8gZnVuY3Rpb24gc3dpdGNoZWQgYnVmZmVyIikpCisgICAgICAgICA7OyBNYWtl
IHN1cmUgYW4gYXBwbHkgZW50cnkgcHJvZHVjZXMgYXQgbGVhc3Qgb25lIHVuZG8gZW50cnksCisg
ICAgICAgICA7OyBzbyB0aGUgdGVzdCBpbiBgdW5kbycgZm9yIGNvbnRpbnVpbmcgYW4gdW5kbyBz
ZXJpZXMKKyAgICAgICAgIDs7IHdpbGwgd29yayByaWdodC4KKyAgICAgICAgICh3aGVuIChlcSBv
bGRsaXN0IGJ1ZmZlci11bmRvLWxpc3QpCisgICAgICAgICAgIChwdXNoIChsaXN0ICdhcHBseSAn
Y2RyIG5pbCkgYnVmZmVyLXVuZG8tbGlzdCkpKSkKKyAgICAgIDs7IEVsZW1lbnQgKFNUUklORyAu
IFBPUykgbWVhbnMgU1RSSU5HIHdhcyBkZWxldGVkLgorICAgICAgKGAoLChhbmQgc3RyaW5nIChw
cmVkIHN0cmluZ3ApKSAuICwoYW5kIHBvcyAocHJlZCBpbnRlZ2VycCkpKQorICAgICAgICh3aGVu
IChsZXQgKChhcG9zIChhYnMgcG9zKSkpCisgICAgICAgICAgICAgICAob3IgKDwgYXBvcyAocG9p
bnQtbWluKSkgKD4gYXBvcyAocG9pbnQtbWF4KSkpKQorICAgICAgICAgKGVycm9yICJDaGFuZ2Vz
IHRvIGJlIHVuZG9uZSBhcmUgb3V0c2lkZSB2aXNpYmxlIHBvcnRpb24gb2YgYnVmZmVyIikpCisg
ICAgICAgOzsgSW5zZXJ0IHN0cmluZyBhbmQgYWRqdXN0IHBvaW50CisgICAgICAgKGlmICg8IHBv
cyAwKQorICAgICAgICAgICAocHJvZ24KKyAgICAgICAgICAgICAoZ290by1jaGFyICgtIHBvcykp
CisgICAgICAgICAgICAgKGluc2VydCBzdHJpbmcpKQorICAgICAgICAgKGdvdG8tY2hhciBwb3Mp
CisgICAgICAgICAoaW5zZXJ0IHN0cmluZykKKyAgICAgICAgIChnb3RvLWNoYXIgcG9zKSkpCisg
ICAgICA7OyAoTUFSS0VSIC4gT0ZGU0VUKSBtZWFucyBhIG1hcmtlciBNQVJLRVIgd2FzIGFkanVz
dGVkIGJ5IE9GRlNFVC4KKyAgICAgIChgKCwoYW5kIG1hcmtlciAocHJlZCBtYXJrZXJwKSkgLiAs
KGFuZCBvZmZzZXQgKHByZWQgaW50ZWdlcnApKSkKKyAgICAgICAod2hlbiAobWFya2VyLWJ1ZmZl
ciBtYXJrZXIpCisgICAgICAgICAoc2V0LW1hcmtlciBtYXJrZXIKKyAgICAgICAgICAgICAgICAg
ICAgICgtIG1hcmtlciBvZmZzZXQpCisgICAgICAgICAgICAgICAgICAgICAobWFya2VyLWJ1ZmZl
ciBtYXJrZXIpKSkpCisgICAgICAoXyAoZXJyb3IgIlVucmVjb2duaXplZCBlbnRyeSBpbiB1bmRv
IGxpc3QgJVMiIG5leHQpKSkKKyAgICAobm90IChlcSBvbGRsaXN0IGJ1ZmZlci11bmRvLWxpc3Qp
KSkpCiAKIDs7IERlZXAgY29weSBvZiBhIGxpc3QKIChkZWZ1biB1bmRvLWNvcHktbGlzdCAobGlz
dCkKQEAgLTIzNTMsMTcgKzIzOTEsMjIgQEAgUmV0dXJuIHdoYXQgcmVtYWlucyBvZiB0aGUgbGlz
dC4iCiAgICAgZWx0KSkKIAogKGRlZnVuIHVuZG8tc3RhcnQgKCZvcHRpb25hbCBiZWcgZW5kKQot
ICAiU2V0IGBwZW5kaW5nLXVuZG8tbGlzdCcgdG8gdGhlIGZyb250IG9mIHRoZSB1bmRvIGxpc3Qu
Ci1UaGUgbmV4dCBjYWxsIHRvIGB1bmRvLW1vcmUnIHdpbGwgdW5kbyB0aGUgbW9zdCByZWNlbnRs
eSBtYWRlIGNoYW5nZS4KLUlmIEJFRyBhbmQgRU5EIGFyZSBzcGVjaWZpZWQsIHRoZW4gb25seSB1
bmRvIGVsZW1lbnRzCi10aGF0IGFwcGx5IHRvIHRleHQgYmV0d2VlbiBCRUcgYW5kIEVORCBhcmUg
dXNlZDsgb3RoZXIgdW5kbyBlbGVtZW50cwotYXJlIGlnbm9yZWQuICBJZiBCRUcgYW5kIEVORCBh
cmUgbmlsLCBhbGwgdW5kbyBlbGVtZW50cyBhcmUgdXNlZC4iCisgICJTZXQgYHBlbmRpbmctdW5k
by1saXN0JyB0byBiZWdpbiBhIHJ1biBvZiB1bmRvcy4gIFRoZSBuZXh0CitjYWxsIHRvIGB1bmRv
LW1vcmUnIHdpbGwgdW5kbyB0aGUgbmV4dCBjaGFuZ2UgZ3JvdXAuICBJZiBCRUcgYW5kCitFTkQg
YXJlIHNwZWNpZmllZCwgdGhlbiBvbmx5IHVuZG8gZWxlbWVudHMgdGhhdCBhcHBseSB0byB0ZXh0
CitiZXR3ZWVuIEJFRyBhbmQgRU5EIGFyZSB1c2VkOyBvdGhlciB1bmRvIGVsZW1lbnRzIGFyZSBp
Z25vcmVkLgorSWYgQkVHIGFuZCBFTkQgYXJlIG5pbCwgYWxsIHVuZG8gZWxlbWVudHMgYXJlIHVz
ZWQuIgogICAoaWYgKGVxIGJ1ZmZlci11bmRvLWxpc3QgdCkKICAgICAgICh1c2VyLWVycm9yICJO
byB1bmRvIGluZm9ybWF0aW9uIGluIHRoaXMgYnVmZmVyIikpCiAgIChzZXRxIHBlbmRpbmctdW5k
by1saXN0CiAJKGlmIChhbmQgYmVnIGVuZCAobm90ICg9IGJlZyBlbmQpKSkKLQkgICAgKHVuZG8t
bWFrZS1zZWxlY3RpdmUtbGlzdCAobWluIGJlZyBlbmQpIChtYXggYmVnIGVuZCkpCi0JICBidWZm
ZXItdW5kby1saXN0KSkpCisJICAgICh1bmRvLW1ha2UtcmVnaW9uYWwtbGlzdCAobWluIGJlZyBl
bmQpIChtYXggYmVnIGVuZCkpCisgICAgICAgICAgKGxldCAoKGxpc3QtaSBidWZmZXItdW5kby1s
aXN0KQorICAgICAgICAgICAgICAgIGFzc29jLWxpc3QpCisgICAgICAgICAgICAod2hpbGUgbGlz
dC1pCisgICAgICAgICAgICAgIChwdXNoIChjb25zIChjYXIgbGlzdC1pKSBsaXN0LWkpIGFzc29j
LWxpc3QpCisgICAgICAgICAgICAgIChwb3AgbGlzdC1pKSkKKyAgICAgICAgICAgIChucmV2ZXJz
ZSBhc3NvYy1saXN0KSkpKSkKIAogOzsgVGhlIHBvc2l0aW9ucyBnaXZlbiBpbiBlbGVtZW50cyBv
ZiB0aGUgdW5kbyBsaXN0IGFyZSB0aGUgcG9zaXRpb25zCiA7OyBhcyBvZiB0aGUgdGltZSB0aGF0
IGVsZW1lbnQgd2FzIHJlY29yZGVkIHRvIHVuZG8gaGlzdG9yeS4gIEluCkBAIC0yNDI0LDE1ICsy
NDY3LDE3IEBAIGFyZSBpZ25vcmVkLiAgSWYgQkVHIGFuZCBFTkQgYXJlIG5pbCwgYWxsIHVuZG8g
ZWxlbWVudHMgYXJlIHVzZWQuIgogOzsgImNjYWFiYWQiLCBhcyB0aG91Z2ggdGhlIGZpcnN0ICJk
IiBiZWNhbWUgZGV0YWNoZWQgZnJvbSB0aGUKIDs7IG9yaWdpbmFsICJkZGQiIGluc2VydGlvbi4g
IFRoaXMgcXVpcmsgaXMgYSBGSVhNRS4KIAotKGRlZnVuIHVuZG8tbWFrZS1zZWxlY3RpdmUtbGlz
dCAoc3RhcnQgZW5kKQotICAiUmV0dXJuIGEgbGlzdCBvZiB1bmRvIGVsZW1lbnRzIGZvciB0aGUg
cmVnaW9uIFNUQVJUIHRvIEVORC4KLVRoZSBlbGVtZW50cyBjb21lIGZyb20gYGJ1ZmZlci11bmRv
LWxpc3QnLCBidXQgd2Uga2VlcCBvbmx5IHRoZQotZWxlbWVudHMgaW5zaWRlIHRoaXMgcmVnaW9u
LCBhbmQgZGlzY2FyZCB0aG9zZSBvdXRzaWRlIHRoaXMKLXJlZ2lvbi4gIFRoZSBlbGVtZW50cycg
cG9zaXRpb25zIGFyZSBhZGp1c3RlZCBzbyBhcyB0aGUgcmV0dXJuZWQKLWxpc3QgY2FuIGJlIGFw
cGxpZWQgdG8gdGhlIGN1cnJlbnQgYnVmZmVyLiIKKyhkZWZ1biB1bmRvLW1ha2UtcmVnaW9uYWwt
bGlzdCAoc3RhcnQgZW5kKQorICAiUmV0dXJuIGEgbGlzdCBvZiB1bmRvIGFzc29jaWF0aW9ucyBm
b3IgdGhlIHJlZ2lvbiBTVEFSVCB0byBFTkQsCisKK1RoZSB1bmRvIGFzc29jaWF0aW9ucyBhcmUg
b2YgdGhlIGZvcm0gKEFESlVTVEVELUVMVAorLiBPUklHLVVORE8tTElTVCkgYW5kIGFyZSBhcyBk
b2N1bWVudGVkIGZvcgorcGVuZGluZy11bmRvLWxpc3QuIE9ubHkgYXNzb2NpYXRpb25zIGZvciBl
bGVtZW50cyBseWluZyBpbnNpZGUKK3RoZSByZWdpb24gYXJlIGluY2x1ZGVkLiBUaGVpciBwb3Np
dGlvbnMgYXJlIGFkanVzdGVkIGJhc2VkIG9uCit0aGUgZGlzY2FyZGVkIGVsZW1lbnRzIG5vdCBm
dWxseSBpbiB0aGUgcmVnaW9uLiIKICAgKGxldCAoKHVsaXN0IGJ1ZmZlci11bmRvLWxpc3QpCi0g
ICAgICAgIDs7IEEgbGlzdCBvZiBwb3NpdGlvbiBhZGp1c3RlZCB1bmRvIGVsZW1lbnRzIGluIHRo
ZSByZWdpb24uCi0gICAgICAgIChzZWxlY3RpdmUtbGlzdCAobGlzdCBuaWwpKQorICAgICAgICA7
OyBUaGUgbGlzdCBvZiAoQURKVVNURUQtRUxUIC4gT1JJRy1VTkRPLUxJU1QpIHRvIHJldHVybgor
ICAgICAgICAoc2VsZWN0aXZlLWxpc3QgKGxpc3QgKGNvbnMgbmlsIG5pbCkpKQogICAgICAgICA7
OyBBIGxpc3Qgb2YgdW5kby1kZWx0YXMgZm9yIG91dCBvZiByZWdpb24gdW5kbyBlbGVtZW50cy4K
ICAgICAgICAgdW5kby1kZWx0YXMKICAgICAgICAgdW5kby1lbHQpCkBAIC0yNDQzLDE0ICsyNDg4
LDE2IEBAIGxpc3QgY2FuIGJlIGFwcGxpZWQgdG8gdGhlIGN1cnJlbnQgYnVmZmVyLiIKICAgICAg
IChzZXRxIHVuZG8tZWx0IChjYXIgdWxpc3QpKQogICAgICAgKGNvbmQKICAgICAgICAoKG51bGwg
dW5kby1lbHQpCi0gICAgICAgIDs7IERvbid0IHB1dCB0d28gbmlscyB0b2dldGhlciBpbiB0aGUg
bGlzdAotICAgICAgICAod2hlbiAoY2FyIHNlbGVjdGl2ZS1saXN0KQotICAgICAgICAgIChwdXNo
IG5pbCBzZWxlY3RpdmUtbGlzdCkpKQorICAgICAgICAobGV0ICg7OyBVbmRvIGJvdW5kYXJ5IHJl
cHJlc2VudGF0aW9uCisgICAgICAgICAgICAgIChib3VuZGFyeSAoY29ucyBuaWwgbmlsKSkpCisg
ICAgICAgICAgOzsgRG9uJ3QgcHV0IHR3byB1bmRvIGJvdW5kYXJpZXMgdG9nZXRoZXIgaW4gdGhl
IGxpc3QKKyAgICAgICAgICAodW5sZXNzIChlcXVhbCBib3VuZGFyeSAoY2FyIHNlbGVjdGl2ZS1s
aXN0KSkKKyAgICAgICAgICAgIChwdXNoIGJvdW5kYXJ5IHNlbGVjdGl2ZS1saXN0KSkpKQogICAg
ICAgICgoYW5kIChjb25zcCB1bmRvLWVsdCkgKGVxIChjYXIgdW5kby1lbHQpIHQpKQogICAgICAg
ICA7OyBUaGlzIGlzIGEgIndhcyB1bm1vZGlmaWVkIiBlbGVtZW50LiAgS2VlcCBpdAogICAgICAg
ICA7OyBpZiB3ZSBoYXZlIGtlcHQgZXZlcnl0aGluZyB0aHVzIGZhci4KICAgICAgICAgKHdoZW4g
KG5vdCB1bmRvLWRlbHRhcykKLSAgICAgICAgICAocHVzaCB1bmRvLWVsdCBzZWxlY3RpdmUtbGlz
dCkpKQorICAgICAgICAgIChwdXNoIChjb25zIHVuZG8tZWx0IHVsaXN0KSBzZWxlY3RpdmUtbGlz
dCkpKQogICAgICAgIDs7IFNraXAgb3ZlciBtYXJrZXIgYWRqdXN0bWVudHMsIGluc3RlYWQgcmVs
eWluZwogICAgICAgIDs7IG9uIGZpbmRpbmcgdGhlbSBhZnRlciAoVEVYVCAuIFBPUykgZWxlbWVu
dHMKICAgICAgICAoKG1hcmtlcnAgKGNhci1zYWZlIHVuZG8tZWx0KSkKQEAgLTI0NjEsMjAgKzI1
MDgsMzAgQEAgbGlzdCBjYW4gYmUgYXBwbGllZCB0byB0aGUgY3VycmVudCBidWZmZXIuIgogICAg
ICAgICAgIChpZiAodW5kby1lbHQtaW4tcmVnaW9uIGFkanVzdGVkLXVuZG8tZWx0IHN0YXJ0IGVu
ZCkKICAgICAgICAgICAgICAgKHByb2duCiAgICAgICAgICAgICAgICAgKHNldHEgZW5kICgrIGVu
ZCAoY2RyICh1bmRvLWRlbHRhIGFkanVzdGVkLXVuZG8tZWx0KSkpKQotICAgICAgICAgICAgICAg
IChwdXNoIGFkanVzdGVkLXVuZG8tZWx0IHNlbGVjdGl2ZS1saXN0KQorICAgICAgICAgICAgICAg
IChwdXNoIChjb25zIGFkanVzdGVkLXVuZG8tZWx0IHVsaXN0KSBzZWxlY3RpdmUtbGlzdCkKICAg
ICAgICAgICAgICAgICA7OyBLZWVwIChNQVJLRVIgLiBBREpVU1RNRU5UKSBpZiB0aGVpciAoVEVY
VCAuIFBPUykgd2FzCiAgICAgICAgICAgICAgICAgOzsga2VwdC4gIHByaW1pdGl2ZS11bmRvIG1h
eSBkaXNjYXJkIHRoZW0gbGF0ZXIuCiAgICAgICAgICAgICAgICAgKHdoZW4gKGFuZCAoc3RyaW5n
cCAoY2FyLXNhZmUgYWRqdXN0ZWQtdW5kby1lbHQpKQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKGludGVnZXJwIChjZHItc2FmZSBhZGp1c3RlZC11bmRvLWVsdCkpKQogICAgICAgICAgICAg
ICAgICAgKGxldCAoKGxpc3QtaSAoY2RyIHVsaXN0KSkpCiAgICAgICAgICAgICAgICAgICAgICh3
aGlsZSAobWFya2VycCAoY2FyLXNhZmUgKGNhciBsaXN0LWkpKSkKLSAgICAgICAgICAgICAgICAg
ICAgICAocHVzaCAocG9wIGxpc3QtaSkgc2VsZWN0aXZlLWxpc3QpKSkpKQorICAgICAgICAgICAg
ICAgICAgICAgIChsZXQgKChtYXJrZXItYWRqIChwb3AgbGlzdC1pKSkpCisgICAgICAgICAgICAg
ICAgICAgICAgICAocHVzaCAoY29ucyBtYXJrZXItYWRqIG1hcmtlci1hZGopCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBzZWxlY3RpdmUtbGlzdCkpKSkpKQogICAgICAgICAgICAgKGxl
dCAoKGRlbHRhICh1bmRvLWRlbHRhIHVuZG8tZWx0KSkpCiAgICAgICAgICAgICAgICh3aGVuICgv
PSAwIChjZHIgZGVsdGEpKQogICAgICAgICAgICAgICAgIChwdXNoIGRlbHRhIHVuZG8tZGVsdGFz
KSkpKSkpKQogICAgICAgKHBvcCB1bGlzdCkpCiAgICAgKG5yZXZlcnNlIHNlbGVjdGl2ZS1saXN0
KSkpCiAKKyhkZWZ1biB1bmRvLW1ha2Utc2VsZWN0aXZlLWxpc3QgKHN0YXJ0IGVuZCkKKyAgIlJl
YWxpemUgYSBmdWxsIHNlbGVjdGl2ZSB1bmRvIGxpc3QgcGVyCit1bmRvLW1ha2UtcmVnaW9uYWwt
Z2VuZXJhdG9yLiIKKyAgKG1hcGNhciAjJ2NhciAodW5kby1tYWtlLXJlZ2lvbmFsLWxpc3Qgc3Rh
cnQgZW5kKSkpCisobWFrZS1vYnNvbGV0ZSAndW5kby1tYWtlLXNlbGVjdGl2ZS1saXN0CisgICAg
ICAgICAgICAgICAiVXNlIHVuZG8tbWFrZS1yZWdpb25hbC1saXN0IGluc3RlYWQuIgorICAgICAg
ICAgICAgICAgIjI0LjUiKQorCiAoZGVmdW4gdW5kby1lbHQtaW4tcmVnaW9uICh1bmRvLWVsdCBz
dGFydCBlbmQpCiAgICJEZXRlcm1pbmUgd2hldGhlciBVTkRPLUVMVCBmYWxscyBpbnNpZGUgdGhl
IHJlZ2lvbiBTVEFSVCAuLi4gRU5ELgogSWYgaXQgY3Jvc3NlcyB0aGUgZWRnZSwgd2UgcmV0dXJu
IG5pbC4K
--001a11c2ed6ceff48804fa7a2cf3--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16411: undo-only bugs
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 19 Jun 2014 21:36:02 +0000
Resent-Message-ID: <handler.16411.B16411.140321372311479 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16411
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Barry OReilly <gundaetiapo@HIDDEN>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Received: via spool by 16411-submit <at> debbugs.gnu.org id=B16411.140321372311479
          (code B ref 16411); Thu, 19 Jun 2014 21:36:02 +0000
Received: (at 16411) by debbugs.gnu.org; 19 Jun 2014 21:35:23 +0000
Received: from localhost ([127.0.0.1]:53520 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WxjzO-0002z3-GI
	for submit <at> debbugs.gnu.org; Thu, 19 Jun 2014 17:35:22 -0400
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:11755)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WxjzL-0002yo-IJ
 for 16411 <at> debbugs.gnu.org; Thu, 19 Jun 2014 17:35:20 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIImAQEEViMQCzQSFBgNJIgM0hkXjnoHhDgEqRmBaoNMIQ
X-IPAS-Result: ArUGAIDvNVNLd+D9/2dsb2JhbABZgwaDSsA9gRcXdIImAQEEViMQCzQSFBgNJIgM0hkXjnoHhDgEqRmBaoNMIQ
X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="68435554"
Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home)
 ([75.119.224.253])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 19 Jun 2014 17:35:13 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 90C3760D16; Thu, 19 Jun 2014 17:35:13 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwv4mzgvbng.fsf-monnier+emacsbugs@HIDDEN>
References: <CAFM41H1pg4uBV3YDfMX=gP=KH2jmdZ4ha7-BWZAcdL8gYrvH=Q@HIDDEN>
 <jwvbnv0tagh.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H2hSaiShoNuyFsg92XjS4W_pJ65Ema2cfjDrOqxQ0u_YA@HIDDEN>
 <jwvppjfpzy7.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H0JhLL=RNcFCohG=UHArDCy__0mnKnmfTvrH=zE27aLkg@HIDDEN>
 <jwvwqdnnrbd.fsf-monnier+emacsbugs@HIDDEN>
 <CAFM41H08EvW3nrrrGbaD3y4YbjY0D1sefPLbTzenSFFSLNLvag@HIDDEN>
Date: Thu, 19 Jun 2014 17:35:13 -0400
In-Reply-To: <CAFM41H08EvW3nrrrGbaD3y4YbjY0D1sefPLbTzenSFFSLNLvag@HIDDEN>
 (Barry OReilly's message of "Wed, 28 May 2014 14:42:33 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

> +  "The pending undo elements in a run of consecutive undo commands.
> +Specifically, this is a list of assocations of the
> +form (ADJUSTED-ELT . ORIG-UNDO-LIST).  ADJUSTED-ELT is an undo
[...]
> -    (let ((equiv (gethash pending-undo-list undo-equiv-table)))
> +    ;; Check to see whether we're hitting a redo record
> +    (let ((equiv (gethash (cdr-safe pending-undo-list) undo-equiv-table)))

Why take the cdr of pending-undo-list?  IOW why skip the first element?
Oh, and please punctuate your comments.

> -	(setq pending-undo-list equiv)))
> +	(setq pending-undo-list (cons (car equiv) equiv))))

I guess this brings the same question as above.

> +    (let ((list buffer-undo-list)
> +          (new-equiv (cdr-safe pending-undo-list)))

And same here.

> +          (when (undo-primitive-elt elt)
> +            ;; Map the new undo element to what it undid.  Not aware
> +            ;; yet of cases where we want to map all new elements.
> +            (puthash buffer-undo-list orig-tail undo-redo-table))

We should only do that in those cases where undo-equiv-table can't be
used.

Also, why did you have to move the valid-marker-adjustments thingy out
of undo-primitive-elt?


        Stefan

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.