From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.bugs Subject: bug#16411: undo-only bugs Date: Sat, 11 Jan 2014 00:09:26 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1133407eb566cf04efaad85a X-Trace: ger.gmane.org 1389417015 30599 80.91.229.3 (11 Jan 2014 05:10:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 05:10:15 +0000 (UTC) Cc: 16411@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 11 06:10:21 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W1qpu-0001fD-R2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Jan 2014 06:10:19 +0100 Original-Received: from localhost ([::1]:60184 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1qpu-0000RQ-5H for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Jan 2014 00:10:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1qpk-0000R3-W6 for bug-gnu-emacs@gnu.org; Sat, 11 Jan 2014 00:10:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1qpe-0002ZP-VM for bug-gnu-emacs@gnu.org; Sat, 11 Jan 2014 00:10:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1qpe-0002Yy-QW for bug-gnu-emacs@gnu.org; Sat, 11 Jan 2014 00:10:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W1qpe-0003PD-G7 for bug-gnu-emacs@gnu.org; Sat, 11 Jan 2014 00:10:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Jan 2014 05:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16411 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16411-submit@debbugs.gnu.org id=B16411.138941696913020 (code B ref 16411); Sat, 11 Jan 2014 05:10:02 +0000 Original-Received: (at 16411) by debbugs.gnu.org; 11 Jan 2014 05:09:29 +0000 Original-Received: from localhost ([127.0.0.1]:45956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1qp6-0003Nw-JK for submit@debbugs.gnu.org; Sat, 11 Jan 2014 00:09:28 -0500 Original-Received: from mail-oa0-f49.google.com ([209.85.219.49]:42602) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1qp4-0003Nk-Pg for 16411@debbugs.gnu.org; Sat, 11 Jan 2014 00:09:27 -0500 Original-Received: by mail-oa0-f49.google.com with SMTP id n16so5941081oag.36 for <16411@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== X-Received: by 10.60.44.179 with SMTP id f19mr11312635oem.43.1389416966086; Fri, 10 Jan 2014 21:09:26 -0800 (PST) Original-Received: by 10.76.114.74 with HTTP; Fri, 10 Jan 2014 21:09:26 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:83271 Archived-At: --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
> I guess I do have some idea how to do it, but it look= s like a lot of
> work, since we have to adjust the positions in the = rest of
> pending-undo-list.

Are you saying the buffer positio= ns in the undo data become
invalidated? That could indeed be a detail I missed. Let me take a
close= r look.

> Right: the loop that undoes N steps (either in undo-mor= e or in undo
> if we change undo to only call undo-more with a 1) nee= ds 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-tabl= e's value type has a new format that could conceivably
break user co= de, 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.

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

--001a1133407eb566cf04efaad85a--