Received: (at 16411) by debbugs.gnu.org; 19 Jun 2014 21:35:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 19 17:35:23 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <16411 <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.Received: (at 16411) by debbugs.gnu.org; 28 May 2014 18:42:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 28 14:42:51 2014 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> Subject: Re: undo-only bugs From: Barry OReilly <gundaetiapo@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/mixed; boundary=001a11c2ed6ceff48804fa7a2cf3 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16411 Cc: 16411 <16411 <at> debbugs.gnu.org> 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'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--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 15 May 2014 13:00:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 15 09:00:31 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <16411 <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.Received: (at 16411) by debbugs.gnu.org; 15 May 2014 03:51:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 23:51:14 2014 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> Subject: Re: undo-only bugs From: Barry OReilly <gundaetiapo@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary=001a11c32246e2f4fe04f9683492 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16411 Cc: 16411 <16411 <at> debbugs.gnu.org> 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">> I've never heard anyone bump into this "Y un= do-redos of X" problem,<br>> so I don't think optimizing it is = worth the trouble.<br><br>Happens to me all the time.<br><br>> If anythi= ng should be done with it, I think it'd be to *cut* the<br> > 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't= want to change.<br><br>> I'm not completely convinced that this gen= erator is worthwhile<br> <br>Ok, I'll lose it then.<br><br>>> I originally set out to do t= his, but making the weak references<br>>> work seemed overly tricky t= o me. The value stored in<br>>> undo-redo-table would need to be non = weak with weak references to<br> >> undo elements. I supposed this would mean many one element weak<br= >>> hash tables. That seems dodgy.<br><br>> Hmm... that'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--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 15 May 2014 02:23:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 22:23:45 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <16411 <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 14 May 2014 21:57:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 17:57:02 2014
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>
Subject: Re: undo-only bugs
From: Barry OReilly <gundaetiapo@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c3224615af9504f963420c
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 16411
Cc: 16411 <16411 <at> debbugs.gnu.org>
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">> You talk here about "undo element", but AFA=
ICT this actually points<br>> to "a list of undo elements" (wh=
ere the first element of that list<br>> is presumably the "undo ele=
ment" you mean). Please clarify.<br>
<br>Yes, that's right. The first element is the "undo element"=
; referred<br>to. The cons is put in the hash table to facilitate recursive=
lookup.<br><br>> My guess is that the "undo-only" case would =
skip redo entries in<br>
> much the same way as undo-in-region skips "out of bounds" en=
tries<br>> (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's worth noting that undo-only might have to =
"mop up" 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>> Combined with the =
fact that undo-redo-table contains entries for<br>> every redo element r=
ather than for every redo group, I'm slightly<br>
> 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 "Y und=
o-redos of X" 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>> [ Nitpick: the first line of the docstring should sta=
nd on its own.=C2=A0 ]<br><br>I don't understand, I thought I formatted=
the docstring like others,<br>
and did M-q it.<br><br>> IIUC this undo-redo-table business is only nece=
ssary because of<br>> undo-in-region. So I think we should strive to min=
imize the changes<br>> to the way undo works in the absence of undo-in-r=
egion. I understand<br>
> that the change can't be all localized in undo-in-region (because =
of<br>> the need to skip "redo-in-region" during normal undo-o=
nly,<br>> basically), but we still should try to aim in that direction.<=
br>
<br>I think you're saying to not pursue the use of a closure to generat=
e<br>successive undo elements as needed? I'm fine with that, but I did =
so<br>because:<br><br>=C2=A0 =E2=80=A2 I'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's not a big conc=
ern.<br><br>=C2=A0 =E2=80=A2 I'm concerned that undo-make-selective-lis=
t'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>> IIUC the crux of the matter is how to record the redo data for an<br=
>> undo-in-region. The way I see it, for such a "redo-in-region&quo=
t; group,<br>
> we indeed need to remember which elements it undid (and which ones<br>=
> it skipped instead), but we could store that info as a single entry<br=
>> 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--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 14 May 2014 19:55:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 15:55:57 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <16411 <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 14 May 2014 18:45:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 14:45:48 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <16411 <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 14 May 2014 18:07:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 14:07:09 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <16411 <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.Received: (at 16411) by debbugs.gnu.org; 14 May 2014 13:32:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 09:32:15 2014 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> Subject: bug#16411: undo-only bugs From: Barry OReilly <gundaetiapo@HIDDEN> To: 16411 <16411 <at> debbugs.gnu.org>, Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary=089e013cb828baad3304f95c3479 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16411 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">> 1: undo-only in region doesn't work.<br><br>+2014-05-13 Stefan Monnier <<a href="mailto:monnier@HIDDEN">monnier@HIDDEN</a>><br>+<br>+ * simple.el (undo-make-selective-list): Obey undo-no-redo.<br> <br>Right, this one didn't need the refactor. Thanks.<br><br></div> --089e013cb828baad3304f95c3479--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 13 May 2014 15:01:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 13 11:01:43 2014
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>
Subject: Re: undo-only bugs
From: Barry OReilly <gundaetiapo@HIDDEN>
To: 16411 <16411 <at> debbugs.gnu.org>, Stefan Monnier <monnier@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 16411
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.
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 27 Feb 2014 05:05:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 27 00:05:13 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: bug#16411: undo in region corrupts existing text
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-Debbugs-Envelope-To: 16411
Cc: 16411 <at> debbugs.gnu.org
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 26 Feb 2014 15:20:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 26 10:20:20 2014
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>
Subject: Re: bug#16411: undo in region corrupts existing text
From: Barry OReilly <gundaetiapo@HIDDEN>
To: 16411 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary=047d7b5d42fcfdfced04f350bd9e
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 16411
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."<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 (>=3D (abs (cdr undo-elt)) start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 (< (abs (cdr undo-elt)) end)))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 (<=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--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 18 Feb 2014 17:41:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 12:41:19 2014
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>
Subject: bug#16411: undo-only bugs
From: Barry OReilly <gundaetiapo@HIDDEN>
To: 16411 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary=001a11c2903c3bea2c04f2b1c55c
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 16411
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">>=A0=A0 ;; (BEGIN . END)<br>>=A0=A0 (and (>=3D (c=
ar undo-elt) start)<br>>=A0=A0=A0=A0=A0=A0=A0 (<=3D (cdr undo-elt) en=
d))<br>>=A0=A0=A0=A0=A0=A0=A0=A0 ^^<br>> <br>>=A0=A0 ;; (TEXT . PO=
SITION)<br>>=A0=A0 (and (>=3D (abs (cdr undo-elt)) start)<br>
>=A0=A0=A0=A0=A0=A0=A0 (< (abs (cdr undo-elt)) end))<br>>=A0=A0=A0=
=A0=A0=A0=A0=A0 ^<br><br>Using 'git log -L' on these two code fragm=
ents, I found the (BEGIN .<br>END) case changed in this commit to "Fix=
one-off error at END".<br>
<br>commit 9debee7a5e6ebc0c32141619248e7390f1476946<br>Author: Richard M. S=
tallman <<a href=3D"mailto:rms@HIDDEN">rms@HIDDEN</a>><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."<br>=A0If it crosses the edge, we =
return nil."<br>=A0=A0 (cond ((integerp undo-elt)<br>=A0=A0=A0=A0=A0=
=A0=A0=A0 (and (>=3D undo-elt start)<br>
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (<=A0 undo-elt end)))<br>+=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (<=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."<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 (>=3D (cdr alist-elt) =
start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (< (cdr alist-elt)=
end))))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (<=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 (>=3D (car tai=
l) start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (< (cdr tail) e=
nd))))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (<=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 (>=3D (car undo-el=
t) start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (< (cdr undo-elt) end=
)))))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (<=3D (cdr undo-elt) end)=
))))<br>=A0<br>=A0(defun undo-elt-crosses-region (undo-elt start end)<br>
=A0=A0 "Test whether UNDO-ELT crosses one edge of that region START ..=
. END.<br><br>This didn't change the (TEXT . POSITION) case, which hasn=
'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."<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 (>=3D (abs (cdr u=
ndo-elt)) start)<br>-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (< (abs (cdr u=
ndo-elt)) end)))<br>+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (<=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'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--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.Received: (at 16411) by debbugs.gnu.org; 14 Feb 2014 22:29:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 14 17:29:11 2014 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> Subject: bug#16411: undo-only bugs From: Barry OReilly <gundaetiapo@HIDDEN> To: 16411 <at> debbugs.gnu.org Content-Type: multipart/alternative; boundary=001a11c2903c3794fd04f26555f9 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16411 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">> • ./src/emacs -Q<br>> • In *scratch* at = least twice:<br>> • Insert "aaa"<br>> = ; • Undo<br>> • Select the entire buffer<br>> • = Undo in region with prefix-arg 4<br>> • Observe the wrongful deleti= on of the string: "fer." in the Lisp<br> > comment.<br><br>A more concise recipe:<br><br> &bull= ; ./src/emacs -Q<br> • In *scratch* insert "aaa"<br>&n= bsp; • Undo<br> • Select the entire buffer<br> •= Undo in region<br> • Observe the wrongful deletion of the perio= d in the Lisp comment.<br> <br></div> --001a11c2903c3794fd04f26555f9--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 14 Feb 2014 18:51:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 14 13:51:48 2014
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>
Subject: Re: bug#16411: undo-only bugs
From: Barry OReilly <gundaetiapo@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11362860c82e0e04f2624bfb
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 16411
Cc: 16411 <at> debbugs.gnu.org
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's another bug with recipe. Again, each "inse=
rt" should be a<br>change group.<br><br> • ./src/emacs -Q<b=
r> • In *scratch* at least twice:<br> • I=
nsert "aaa"<br> • Undo<br>
• Select the entire buffer<br> • Undo in region with=
prefix-arg 4<br> • Observe the wrongful deletion of the string:=
"fer." in the Lisp<br> 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> ;; (BEGIN . END)<br>&nbs=
p; (and (>=3D (car undo-elt) start)<br> &nb=
sp; (<=3D (cdr undo-elt) end))<br> &n=
bsp; ^^<br><br> ;; (TEXT . POSITION)<br> (and (>=3D (abs (cd=
r undo-elt)) start)<br>
(< (abs (cdr undo-elt)) end))<br>&n=
bsp; ^<br><br>One is compared to the en=
d by <=3D and the other by <. 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=
's not valid given the restoration of "aaa" was just excluded=
.<br>
It's now pear shaped.<br><br>I'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--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.Received: (at 16411) by debbugs.gnu.org; 19 Jan 2014 16:57:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 19 11:57:26 2014 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> Subject: Re: bug#16411: undo-only bugs From: Barry OReilly <gundaetiapo@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary=089e013d0dc033b4f404f055ab14 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16411 Cc: 16411 <at> debbugs.gnu.org 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">> (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't to= o hard or<br>intrusive. I'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>> IIUC, you're= talking of skipping (e.g. in a non-region undo) the<br>> undos that too= k place during undo-in-region, right? If so, I don't<br>> 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>> why not skip all these e= lements in one swoop as we currently do with<br>> undo-equiv-table<br> <br>Because it would not be correct. I constructed recipe 2 in order to<br>= demonstrate the incorrectness.<br><br>> 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'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'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>> the step "Insert = its undone-element in the undo-skip-set" means that<br> > we skip this "redo" element, which means that all the subseq= uent<br>> elements (until the matching undone-element) may have incorrec= t<br>> 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 "Iterate over<br>pending-undo-l= ist", 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's performance right away,<br>e= ven if undo-only doesn't use it after just the first patch.<br><br>>= But it'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--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 19 Jan 2014 03:18:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 22:18:58 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: bug#16411: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <at> debbugs.gnu.org
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 19 Jan 2014 00:58:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 19:58:21 2014
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>
Subject: Re: bug#16411: undo-only bugs
From: Barry OReilly <gundaetiapo@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=089e0122912c1fa7a504f04845c5
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 16411
Cc: 16411 <at> debbugs.gnu.org
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'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 "redo ele=
ment" 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 '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'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 "skip", you can<br>duckduckgo "=
;skip lists".<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'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'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'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'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's more =
I could say about other details, but I'll stop now to get<br>feedback o=
n the overall idea.<br>
<br></div>
--089e0122912c1fa7a504f04845c5--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.Received: (at 16411) by debbugs.gnu.org; 14 Jan 2014 14:00:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 14 09:00:20 2014 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> Subject: Re: bug#16411: undo-only bugs From: Barry OReilly <gundaetiapo@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary=001a11330904901e7504efee9c9e X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16411 Cc: 16411 <at> debbugs.gnu.org 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">> >> Actually, this makes me realize the solution to bug 1 is<br>> >> inadequate. Calling (undo-primitive 1) N times creates N redo<br>> >> records whereas (undo-primitive N) creates one.<br> > > No, primitive-undo does not add any undo boundary.<br><br>> Actually, now I'm not sure what you meant by "redo records".<br>> (primitive-undo N) will undo all the M "records" that appear before<br> > the next Nth undo boundary, and will correspondingly add M redo<br>> "records", but no boundary.<br><br>I took another look at the code and see I was mistaken on this point.<br>I'll work on a patch.<br> <br></div> --001a11330904901e7504efee9c9e--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 14 Jan 2014 01:52:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 13 20:52:07 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: bug#16411: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <at> debbugs.gnu.org
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 14 Jan 2014 00:49:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 13 19:49:44 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: bug#16411: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <at> debbugs.gnu.org
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.Received: (at 16411) by debbugs.gnu.org; 11 Jan 2014 05:09:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 11 00:09:29 2014 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> Subject: Re: bug#16411: undo-only bugs From: Barry OReilly <gundaetiapo@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary=001a1133407eb566cf04efaad85a X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16411 Cc: 16411 <at> debbugs.gnu.org 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">> I guess I do have some idea how to do it, but it look= s like a lot of<br>> work, since we have to adjust the positions in the = rest of<br>> 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>> Right: the loop that undoes N steps (either in undo-mor= e or in undo<br>> if we change undo to only call undo-more with a 1) nee= ds not only to<br> > use undo-equiv-table at each iteration to skip redo entries, but it<br= >> 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's value type has a new format that could conceivably<br>break user co= de, so let'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--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 11 Jan 2014 04:29:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 10 23:29:18 2014
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>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: bug#16411: undo-only bugs
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-Debbugs-Envelope-To: 16411
Cc: 16411 <at> debbugs.gnu.org
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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 11 Jan 2014 03:48:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 10 22:48:40 2014
Received: from localhost ([127.0.0.1]:45897 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1W1pYt-00010N-II
for submit <at> debbugs.gnu.org; Fri, 10 Jan 2014 22:48:39 -0500
Received: from mail-oa0-f46.google.com ([209.85.219.46]:60563)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <gundaetiapo@HIDDEN>) id 1W1pYp-000109-VX
for 16411 <at> debbugs.gnu.org; Fri, 10 Jan 2014 22:48:36 -0500
Received: by mail-oa0-f46.google.com with SMTP id l6so5954038oag.33
for <16411 <at> debbugs.gnu.org>; Fri, 10 Jan 2014 19:48:35 -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=kPoTjxNX0PcqEi8QNIG7OicfmLAKddGzDh0wClD1hTc=;
b=pEl1pn4ItAMj91Zcc7k/1eO0fEF3rkRflgSX3klRAjbxoYfwbu7hg9M/7PjLlqmT6v
v6gjyIgPTAN65Op8SetTHdt5193nm3WkdAN6qRxMB0yMr2MySiOEsif6dtGNG9PBnEZJ
zhez1C0e5xGJ2xJgi42LhpSa6GUJaVhawEq/yDZfAI1mpvbnWrAm36RmiSm/sXsfr9GF
Z4bYoTJc07JBkYlGkBvANALOacD+ljrLmJEcIwTcDNKoU+0mf4jDDdJiRjMe9Ra2jyvI
Ffk/QfUMCbYzef6nLV1YRKuU0PKEHnZWkkFnQF+utagG2St/h4oHkJW749SgkooWE/nW
kq8Q==
MIME-Version: 1.0
X-Received: by 10.60.93.105 with SMTP id ct9mr11347826oeb.12.1389412114954;
Fri, 10 Jan 2014 19:48:34 -0800 (PST)
Received: by 10.76.114.74 with HTTP; Fri, 10 Jan 2014 19:48:34 -0800 (PST)
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>
Subject: Re: bug#16411: undo-only bugs
From: Barry OReilly <gundaetiapo@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7b33d5a08efd3f04efa9b7de
X-Spam-Score: 2.9 (++)
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. [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gundaetiapo[at]gmail.com)
-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 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
X-Debbugs-Envelope-To: 16411
Cc: 16411 <at> debbugs.gnu.org
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.9 (++)
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. [...]
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">> undo-in-region does not implement undo-only, indeed. I think the way<br>> to implement undo-only is to change undo-make-selective-list so it<br>> also skips redo entries (depending on undo-no-redo, obviously) using<br>
> the above while loop.<br><br>I don't see how that'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--
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at 16411) by debbugs.gnu.org; 10 Jan 2014 23:55:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 10 18:55:04 2014
Received: from localhost ([127.0.0.1]:45710 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1W1lup-0002kv-AY
for submit <at> debbugs.gnu.org; Fri, 10 Jan 2014 18:55:03 -0500
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:8292)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <monnier@HIDDEN>) id 1W1luk-0002kQ-KY
for 16411 <at> debbugs.gnu.org; Fri, 10 Jan 2014 18:54:59 -0500
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFABK/CFFFxKG9/2dsb2JhbABEhke4Rxdzgh4BAQQBIzMjBQsLGgIYDgICFBgNJC6HcAauX5JOgSOOVIETA4hhnBmBXoMV
X-IPAS-Result: AgAFABK/CFFFxKG9/2dsb2JhbABEhke4Rxdzgh4BAQQBIzMjBQsLGgIYDgICFBgNJC6HcAauX5JOgSOOVIETA4hhnBmBXoMV
X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44692583"
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 18:54:57 -0500
Received: by pastel.home (Postfix, from userid 20848)
id 334C76045A; Fri, 10 Jan 2014 18:54:57 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Barry OReilly <gundaetiapo@HIDDEN>
Subject: Re: bug#16411: undo-only bugs
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
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 16411
Cc: 16411 <at> debbugs.gnu.org
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 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
bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 10 Jan 2014 22:33:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 10 17:33:49 2014
Received: from localhost ([127.0.0.1]:45673 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1W1keC-0000a3-A8
for submit <at> debbugs.gnu.org; Fri, 10 Jan 2014 17:33:49 -0500
Received: from eggs.gnu.org ([208.118.235.92]:59105)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <gundaetiapo@HIDDEN>) id 1W1ke9-0000Zt-9S
for submit <at> debbugs.gnu.org; Fri, 10 Jan 2014 17:33:46 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <gundaetiapo@HIDDEN>) id 1W1ke7-0002tP-9q
for submit <at> debbugs.gnu.org; Fri, 10 Jan 2014 17:33:44 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:46313)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <gundaetiapo@HIDDEN>) id 1W1ke7-0002tL-6C
for submit <at> debbugs.gnu.org; Fri, 10 Jan 2014 17:33:43 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60821)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <gundaetiapo@HIDDEN>) id 1W1ke5-0002Q5-J1
for bug-gnu-emacs@HIDDEN; Fri, 10 Jan 2014 17:33:43 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <gundaetiapo@HIDDEN>) id 1W1ke3-0002sK-26
for bug-gnu-emacs@HIDDEN; Fri, 10 Jan 2014 17:33:41 -0500
Received: from mail-ob0-x22f.google.com ([2607:f8b0:4003:c01::22f]:33031)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <gundaetiapo@HIDDEN>) id 1W1ke2-0002sD-Qb
for bug-gnu-emacs@HIDDEN; Fri, 10 Jan 2014 17:33:38 -0500
Received: by mail-ob0-f175.google.com with SMTP id uz6so5438152obc.20
for <bug-gnu-emacs@HIDDEN>; Fri, 10 Jan 2014 14:33:38 -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=jaH0NL2Ou5f5oZmLGuOpkNtr7dChkYlj+rOA378PQjs=;
b=Cp+/L378ZMomW31J7MsaWpxqpf69VD6odEgePJx1NiJOa1ydvjmpp67PNMkfvqzNB0
MlRuNTpv2dG6pGxisJU9UuzJNKDpN/521eg1RT2h1P32jp6EDoR3EUgS+mO3zgnbws9h
VhtVGsPzz7NFZYg2T0KPyXD6hkqMgz7G3C488CURIHsHyVwIh+B6FGk2Ci9OMsNyXZXX
5h1Rw9U2rvntEh53fHJ+pQF4rsz8yRH0IFQ2SObWO03Mc8m+tFoxcMgtmYJ9JwryjaTM
pGSRQ0zAqtyOfD0AVZCAAmy9U049J+qpWMMCg/loB2kx/+YNEgMc7mj0LoHvFZYsdBS9
FK4w==
MIME-Version: 1.0
X-Received: by 10.60.118.167 with SMTP id kn7mr10181358oeb.22.1389393217901;
Fri, 10 Jan 2014 14:33:37 -0800 (PST)
Received: by 10.76.114.74 with HTTP; Fri, 10 Jan 2014 14:33:37 -0800 (PST)
Date: Fri, 10 Jan 2014 17:33:37 -0500
Message-ID: <CAFM41H1m2EHLZHq=0pPeGaQ0pic6KE5j6fiAWM_nBP5JZWh8+g@HIDDEN>
Subject: undo-only bugs
From: Barry OReilly <gundaetiapo@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/alternative; boundary=047d7b3a976034d74c04efa551a5
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-Debbugs-Envelope-To: submit
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: -4.0 (----)
--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 "ins=
ert" should be<br>exactly one change group or the recipes may not work=
. I use Evil so<br>
it's easy to arrange for that.<br><br>Recipe 1:<br>=A0 =95 Insert "=
;aaa"<br>=A0 =95 Insert "bbb"<br>=A0 =95 Undo<br>=A0 =95 Ins=
ert "ccc"<br>=A0 =95 Insert "ddd"<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 "redo records" prior to calling<br>undo-more through recurs=
ive lookup in undo-equiv-table. However, it<br>
doesn'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"<br>=A0 =95 Insert "bbb"<br>=A0 =95 Mark region aro=
und "aaa" but not "bbb"<br>
=A0 =95 Undo (in region)<br>=A0 =95 Mark region around "bbb" and =
where "aaa" 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 "redo record" as a cons of buffer-undo-list.<=
br>The value would have prefix-arg number of "undone records" 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'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 "undo undo-i" 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 "Undo!". 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 (< 1<br>
prefix-arg), the echo message should convey more. Possible messages<br>migh=
t be "Undo, redo!" and "Redo, undo, undo! No further undo<br=
>information"<br><br>The reason I'm looking at this code at all is=
that I am investigating<br>
Stefan'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=
'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--
Barry OReilly <gundaetiapo@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#16411; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.