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: Undo in region after markers in undo history relocated Date: Wed, 19 Feb 2014 17:15:52 -0500 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013cba6259e29204f2c9bb69 X-Trace: ger.gmane.org 1392848223 8861 80.91.229.3 (19 Feb 2014 22:17:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Feb 2014 22:17:03 +0000 (UTC) To: 16818@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 19 23:17:11 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 1WGFS2-0006cv-IA for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Feb 2014 23:17:10 +0100 Original-Received: from localhost ([::1]:34219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGFS1-0006Pv-Pa for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Feb 2014 17:17:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGFRx-0006Po-5l for bug-gnu-emacs@gnu.org; Wed, 19 Feb 2014 17:17:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGFRu-00017c-DO for bug-gnu-emacs@gnu.org; Wed, 19 Feb 2014 17:17:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGFRu-00017V-9Y for bug-gnu-emacs@gnu.org; Wed, 19 Feb 2014 17:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WGFRt-0002ar-Oh for bug-gnu-emacs@gnu.org; Wed, 19 Feb 2014 17:17:01 -0500 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 Feb 2014 22:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 16818 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.13928481719895 (code B ref -1); Wed, 19 Feb 2014 22:17:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 19 Feb 2014 22:16:11 +0000 Original-Received: from localhost ([127.0.0.1]:60736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGFR4-0002ZW-09 for submit@debbugs.gnu.org; Wed, 19 Feb 2014 17:16:10 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46250) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WGFR1-0002Z9-9n for submit@debbugs.gnu.org; Wed, 19 Feb 2014 17:16:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGFQs-0000s8-T8 for submit@debbugs.gnu.org; Wed, 19 Feb 2014 17:16:02 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:55187) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGFQs-0000s2-QP for submit@debbugs.gnu.org; Wed, 19 Feb 2014 17:15:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGFQq-0006Lz-5m for bug-gnu-emacs@gnu.org; Wed, 19 Feb 2014 17:15:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGFQn-0000r9-Ek for bug-gnu-emacs@gnu.org; Wed, 19 Feb 2014 17:15:56 -0500 Original-Received: from mail-ob0-x234.google.com ([2607:f8b0:4003:c01::234]:46401) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGFQn-0000r1-70 for bug-gnu-emacs@gnu.org; Wed, 19 Feb 2014 17:15:53 -0500 Original-Received: by mail-ob0-f180.google.com with SMTP id vb8so825868obc.25 for ; Wed, 19 Feb 2014 14:15:52 -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=ABk073nS4thTkKBquASpYY3o4bgZrcDCVaAAXQoTzaQ=; b=BBsRGtIBODpdF/ZXLX5mQdi3yzSQ8lEBO4VVcxjNBuPqEzFJk7+g7xgDZYm6ev2zdL EoVUl0pgVJ6Dk9DVDceOEpgg/W8LVQGEKkbGOIiKrH/bjg4ls9fYHlvJLJOj7yyGoBF4 zk2GJUJFgXOEyVC9bZSfPISwR+H9HvkYkdSL8yHdnzyr6oaTVmqUTLhdexJrLPk3cxRK Sbv05NfdpbCosyfCgRi6gOuwTYZGIkb0kUi8gr0Hwl5JZ6b7hX61IS7KWClSFFKXCaNK mZ3pRSOjgcEVxeq5maoCzMXz3ghmDPS0sI0EYoOQhgsKl9gbVN9PmpnVY+IgFEJPgg0m 9CeQ== X-Received: by 10.182.87.42 with SMTP id u10mr33017984obz.22.1392848152415; Wed, 19 Feb 2014 14:15:52 -0800 (PST) Original-Received: by 10.76.21.84 with HTTP; Wed, 19 Feb 2014 14:15:52 -0800 (PST) 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-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:85915 Archived-At: --089e013cba6259e29204f2c9bb69 Content-Type: text/plain; charset=ISO-8859-1 Strange behavior with the following recipe, using trunk: * ./src/emacs -Q * Move point up two lines * Insert "aaa" * Undo * Move point down two lines * Insert "bbb" * Select "bbb" from end to beginning and delete * Insert "bbb" * Go to line where "aaa" was and select the line from beginning to end * Undo in region * Observe: * "Undo in region!" is echoed in the minibuffer * Unexpectedly, "aaa" is not reinserted back into the buffer * Strangely, the selection mark at BOL moves forward three chars * Undo in region again * Observe: * "aaa" is reinserted, despite selection no longer covering the region where "aaa" was Prior to the first undo in region, buffer-undo-list is: (nil (192 . 195) nil (bbb . 192) (# . -3) (# . -3) (# . -3) nil (192 . 195) (t . 0) nil (aaa . 141) nil (141 . 144) (t . 0) nil (1 . 192) (t . 0)) And after undo-make-selective-list pending-undo-list becomes: (nil (# . -3) (# . -3) nil (aaa . 141) nil (141 . 144) nil) It seems the # is the mark used during selection. When bbb is deleted, the mark is recorded into undo history, and it's still there when the selection mark has moved to position 141 before "aaa". So: > * Unexpectedly, "aaa" is not reinserted back into the buffer is due to the selection mark and another marker occupying their own change group in the filtered pending-undo-list, and that change group is chosen for the first undo in region. > Strangely, the selection mark at BOL moves forward three chars is due to the -3 marker adjustment. > * "aaa" is reinserted, despite selection no longer covering the region where "aaa" was is simply due to pending-undo-list being reused for the second consecutive undo, unaware that the selection mark was adjusted. I haven't determined what those other two markers are. But the general question comes up: how is the undo history meant to know about marker relocations? The code in adjust_markers_for_delete indicates markers are only recorded when they would be in a deleted region or immediately before it, so I think the only circumstance markers form their own undesired change group in the pending-undo-list is when recorded markers were relocated. --089e013cba6259e29204f2c9bb69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Strange behavior with the following recipe, using trunk:
  • ./src/emacs -Q
  • Move point up two lines=
  • Insert "aaa"
  • Undo
  &b= ull; Move point down two lines
  • Insert "bbb"
  • Select "bbb" from end to beginning and delete
&n= bsp; • Insert "bbb"
  • Go to line where "= aaa" was and select the line from beginning to
    e= nd
  • Undo in region
  • Observe:
    • "Undo in region!" is echoed in the mini= buffer
    • Unexpectedly, "aaa" is not re= inserted back into the buffer
    • Strangely, the s= election mark at BOL moves forward three chars
  • Undo in reg= ion again
  • Observe:
    • "aaa" is rein= serted, despite selection no longer covering the
    = ;  region where "aaa" was

Prior to the first undo in = region, buffer-undo-list is:

  (nil (192 . 195) nil (bbb . 192)= (#<marker at 141 in *scratch*> . -3) (#<marker at 192 in *scratch= *> . -3) (#<marker at 190 in *scratch*> . -3) nil (192 . 195) (t .= 0) nil (aaa . 141) nil (141 . 144) (t . 0) nil (1 . 192) (t . 0))

And after undo-make-selective-list pending-undo-list becomes:

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

It seems t= he #<marker at 141 in *scratch*> is the mark used during
selection. When bbb is deleted, the mark is recorded into undo
history, = and it's still there when the selection mark has moved to
position 1= 41 before "aaa". So:

> • Unexpectedly, "aaa&q= uot; is not reinserted back into the buffer

is due to the selection mark and another marker occupying their own
= change group in the filtered pending-undo-list, and that change group
is= chosen for the first undo in region.

> Strangely, the selection = mark at BOL moves forward three chars

is due to the -3 marker adjustment.

> • "aaa" = is reinserted, despite selection no longer covering the
  &nbs= p; region where "aaa" was

is simply due to pending-undo-li= st being reused for the second
consecutive undo, unaware that the selection mark was adjusted.

I ha= ven't determined what those other two markers are. But the general
q= uestion comes up: how is the undo history meant to know about marker
relocations?

The code in adjust_markers_for_delete indicates markers= are only
recorded when they would be in a deleted region or immediately= before
it, so I think the only circumstance markers form their own unde= sired
change group in the pending-undo-list is when recorded markers
were relo= cated.

--089e013cba6259e29204f2c9bb69--