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#16818: Acknowledgement (Undo in region after markers in undo history relocated) Date: Wed, 19 Mar 2014 09:36:17 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2ec9abf802704f4f5bcea X-Trace: ger.gmane.org 1395236236 22477 80.91.229.3 (19 Mar 2014 13:37:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 13:37:16 +0000 (UTC) Cc: 16818@debbugs.gnu.org To: Stefan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 19 14:37:22 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 1WQGgM-00007f-AW for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Mar 2014 14:37:22 +0100 Original-Received: from localhost ([::1]:41340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQGgL-0007L2-Nq for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Mar 2014 09:37:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQGgC-0007G7-TF for bug-gnu-emacs@gnu.org; Wed, 19 Mar 2014 09:37:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQGg3-0004BN-HM for bug-gnu-emacs@gnu.org; Wed, 19 Mar 2014 09:37:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQGg3-0004BD-Bw for bug-gnu-emacs@gnu.org; Wed, 19 Mar 2014 09:37:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WQGg2-0003qi-LH for bug-gnu-emacs@gnu.org; Wed, 19 Mar 2014 09:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Mar 2014 13:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16818 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16818-submit@debbugs.gnu.org id=B16818.139523618414743 (code B ref 16818); Wed, 19 Mar 2014 13:37:02 +0000 Original-Received: (at 16818) by debbugs.gnu.org; 19 Mar 2014 13:36:24 +0000 Original-Received: from localhost ([127.0.0.1]:40837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WQGfP-0003pi-9S for submit@debbugs.gnu.org; Wed, 19 Mar 2014 09:36:24 -0400 Original-Received: from mail-oa0-f54.google.com ([209.85.219.54]:50059) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WQGfK-0003pY-HI for 16818@debbugs.gnu.org; Wed, 19 Mar 2014 09:36:19 -0400 Original-Received: by mail-oa0-f54.google.com with SMTP id n16so8351973oag.13 for <16818@debbugs.gnu.org>; Wed, 19 Mar 2014 06:36:17 -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=yWBB22QAbCHN5znHxE4nGLUVn/Lv0eGULsVjbkegk/o=; b=iQn4uIpkDthYUBdp7Ryn8J3Ttpb/yxQVcdlSObvtXk4HsgvG0pGvYsXLQqYJAiZCvU Dj8R6Fwjg8DFhdGE6jZyAWU+BIhh2K8MRdVvfc6StcWJpv+/zAATaJ0/bCqSsrEd6IMk v0v2AZgq7rcrgphPxiD6y9a+t4VAU55gkKoG/ZpRiRGp59HU8M1T2UKGrp0xxgnci87d mfWaGjk2Zh+4neY5k5VbQaneD0pr4B3pkNUAeHtJtfQDM6tPUisGTJyBEsqaKeDSswQg UfwpTA/41LwY06VVEhf7KbUHxSnt+gTloPlmB77bxKviFC0jIveophHfd62pPSIwcIgE fuzg== X-Received: by 10.182.142.37 with SMTP id rt5mr445722obb.76.1395236177667; Wed, 19 Mar 2014 06:36:17 -0700 (PDT) Original-Received: by 10.76.6.44 with HTTP; Wed, 19 Mar 2014 06:36:17 -0700 (PDT) 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:86969 Archived-At: --001a11c2ec9abf802704f4f5bcea Content-Type: text/plain; charset=ISO-8859-1 > The "move-after" markers will be at (+ del-pos (length > inserted-text)) rather than at del-pos. Right, thanks for catching that flaw. > I'd have the same comment here, but if we emit a warning for sole > marker-adjustments in the "non-region" code, we don't really have to > worry about them here. If you're saying changes under undo-make-selective-list are not necessary, remember that currently it can create a list like: (nil (# . -3) (# . -3) nil (aaa . 141) nil (141 . 144) nil) I don't think the original recipe of this bug report should generate a warning. Rather, I had undo-make-selective-list filter out the marker adjustments so as the above list would have (aaa . 141) at the head. > I think we should only change the entry corresponding to a deletion > such that it directly handles all the immediately following > marker-adjustments They don't always immediately follow. An integer record can be between them. For example, at the end of the undo-test-marker-adjustment-moved test I posted previously, buffer-undo-list is: (nil (1 . 4) nil (abc . 1) 12 (# . -1) nil (1 . 12) (t . 0)) Also, (t sec-high sec-low microsec picosec) entries can be in between. eg it was easy to bring about this buffer-undo-list: Value: (nil (#(" " 0 3 (fontified t)) . 12) (t 20985 26927 0 0) (# . -2) (# . -2) (# . -3) (# . -2)) I suppose some options are: * Implement your proposal but skip over the (t ...) and integer records * Restructure the C code so as marker adjustments are always immediately before deletion records * Revisit the approach of fixing markers that move to unrelated locations. Let me know and thank you for your guidance. --001a11c2ec9abf802704f4f5bcea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> The "move-after" markers will be at (+ del-= pos (length
> inserted-text)) rather than at del-pos.

Right, t= hanks for catching that flaw.

> I'd have the same comment her= e, but if we emit a warning for sole
> marker-adjustments in the "non-region" code, we don't re= ally have to
> worry about them here.

If you're saying cha= nges under undo-make-selective-list are not
necessary, remember that cur= rently it can create a list like:

  (nil (#<marker at 141 in *scratch*> . -3) (#<marker at = 190 in *scratch*>
. -3) nil (aaa . 141) nil (141 . 144) nil)

I= don't think the original recipe of this bug report should generate a warning. Rather, I had undo-make-selective-list filter out the marker
ad= justments so as the above list would have (aaa . 141) at the head.

&= gt; I think we should only change the entry corresponding to a deletion
> such that it directly handles all the immediately following
> ma= rker-adjustments

They don't always immediately follow. An intege= r record can be between
them. For example, at the end of the undo-test-m= arker-adjustment-moved
test I posted previously, buffer-undo-list is:

  (nil (1 . 4) n= il (abc . 1) 12 (#<marker at 7 in  *temp*-216909> . -1) nil (1 .= 12) (t . 0))

Also, (t sec-high sec-low microsec picosec) entries ca= n be in between.
eg it was easy to bring about this buffer-undo-list:

  Value: (= nil
   (#("   " 0 3
   &= nbsp;  (fontified t))
    . 12)
   (t 2= 0985 26927 0 0)
   (#<marker at 12 in foo.py> . -2)
&= nbsp;  (#<marker at 12 in foo.py> . -2)
   (#<marker in no buffer> . -3)
   (#<mark= er in no buffer> . -2))

I suppose some options are:

 = • Implement your proposal but skip over the (t ...) and integer
&n= bsp;   records
  • Restructure the C code so as mark= er adjustments are always
    immediately before deletion records
  • Rev= isit the approach of fixing markers that move to unrelated
  &= nbsp; locations.

Let me know and thank you for your guidance.
--001a11c2ec9abf802704f4f5bcea--