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: Mon, 24 Feb 2014 17:46:11 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0115f368f8aea004f32ebc79 X-Trace: ger.gmane.org 1393282031 1074 80.91.229.3 (24 Feb 2014 22:47:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Feb 2014 22:47:11 +0000 (UTC) Cc: 16818@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 24 23:47:19 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 1WI4Iv-0007AN-MD for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Feb 2014 23:47:17 +0100 Original-Received: from localhost ([::1]:60063 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WI4Iv-00020J-93 for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Feb 2014 17:47:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WI4Im-000205-Vl for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2014 17:47:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WI4Ig-0000qm-U8 for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2014 17:47:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37098) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WI4Ig-0000qi-Q9 for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2014 17:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WI4Ig-0002C9-8e for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2014 17:47: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: Mon, 24 Feb 2014 22:47: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.13932819818371 (code B ref 16818); Mon, 24 Feb 2014 22:47:02 +0000 Original-Received: (at 16818) by debbugs.gnu.org; 24 Feb 2014 22:46:21 +0000 Original-Received: from localhost ([127.0.0.1]:38280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WI4I0-0002Au-1f for submit@debbugs.gnu.org; Mon, 24 Feb 2014 17:46:21 -0500 Original-Received: from mail-oa0-f47.google.com ([209.85.219.47]:55744) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WI4Hx-0002Ae-48 for 16818@debbugs.gnu.org; Mon, 24 Feb 2014 17:46:18 -0500 Original-Received: by mail-oa0-f47.google.com with SMTP id h16so2768936oag.6 for <16818@debbugs.gnu.org>; Mon, 24 Feb 2014 14:46:11 -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=PvVGn6G571S8zcg9JVeGDT1wQg3V3YM55PzBaMU3orU=; b=Y+q5VuqYcbz/aRalP5QA25/5QISAaJUy4h8dpXvgfihmbl+iV1I+4RyefW5XeGT5ig Kg1NPmHo9DxSLRUXxaPglSNCScczLOO0joyeRMHWdP+eagt2nm8ZLLXCOLQekv0rh4Pt Mzn4730nqjXXDyPAVqri8rO2CaQyMHssnBwcIuYZXrI86UQfYWQ42V2DtiHq75WnTPU9 f7KT2LIzrdh/AHoH8hu369b77WStsSVa1QF/mjFy3o9bbMjEv2wAopT/ibK27F9XkR2j Y3q/MMK4klASvU75RxOgV2DsYBzvGtn9kP7xGn+n8U55yaDKOLgHRlv9wbuPTJPxfmAm hOKQ== X-Received: by 10.60.115.68 with SMTP id jm4mr18394789oeb.45.1393281971300; Mon, 24 Feb 2014 14:46:11 -0800 (PST) Original-Received: by 10.76.21.84 with HTTP; Mon, 24 Feb 2014 14:46:11 -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:86160 Archived-At: --089e0115f368f8aea004f32ebc79 Content-Type: text/plain; charset=ISO-8859-1 > > the general question comes up: how is the undo history meant to > > know about marker relocations? > I think the marker adjustment entries in the undo history are > invalid when a marker is relocated elsewhere. I don't see code to > deal with that, so how you would like it to happen? I found the Elisp manual says about moving markers: When you do this, be sure you know whether the marker is used outside of your program, and, if so, what effects will result from moving it--otherwise, confusing things may happen in other parts of Emacs. So if we expand on the guidance as follows: diff --git a/doc/lispref/markers.texi b/doc/lispref/markers.texi index 51b87ab..19386d6 100644 --- a/doc/lispref/markers.texi +++ b/doc/lispref/markers.texi @@ -344,10 +344,12 @@ specify the insertion type, create them with insertion type @section Moving Marker Positions This section describes how to change the position of an existing -marker. When you do this, be sure you know whether the marker is used -outside of your program, and, if so, what effects will result from -moving it---otherwise, confusing things may happen in other parts of -Emacs. +marker. When you do this, be sure you know how the marker is used +outside of your program. For example, moving a marker to an unrelated +new position can cause undo to later adjust the marker incorrectly. +Often when you wish to relocate a marker to an unrelated position, it +is preferable to make a new marker and set the prior one to point +nowhere. @defun set-marker marker position &optional buffer This function moves @var{marker} to @var{position} then we don't need to worry about markers in general, only the particular offending ones of the recipe. As I described, one offending marker is the mark-marker. From the push-mark function: (defun push-mark (&optional location nomsg activate) [...] (setq mark-ring (cons (copy-marker (mark-marker)) mark-ring)) [...] (set-marker (mark-marker) (or location (point)) (current-buffer)) [...] (setq global-mark-ring (cons (copy-marker (mark-marker)) global-mark-ring)) ) Two copies are made and the copies go to the mark-ring and global-mark-ring. The mark continues to be the same marker object under eq as before, only mutated. Consequently, not only does undo adjust a marker it shouldn't have, but it doesn't adjust the copies in the rings when it should have. What makes more sense to me is that the old value of mark-marker is pushed onto the rings, then a new marker object is created to become the value of mark-marker. Then the marker adjustment records would reference the right markers. Effectively this means the mark would follow the advice of the Elisp manual excerpt above. I welcome your guidance about what the right way to solve this bug is. Thank you. --089e0115f368f8aea004f32ebc79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> > the general question comes up: how is the undo h= istory meant to
> > know about marker relocations?

> I t= hink the marker adjustment entries in the undo history are
> invalid = when a marker is relocated elsewhere. I don't see code to
> deal with that, so how you would like it to happen?

I found the= Elisp manual says about moving markers:

  When you do this, be= sure you know whether the marker is used
  outside of your program= , and, if so, what effects will result from
  moving it—otherwise, confusing things may happen in other part= s of
  Emacs.

So if we expand on the guidance as follows:
diff --git a/doc/lispref/markers.texi b/doc/lispref/markers.texi
in= dex 51b87ab..19386d6 100644
--- a/doc/lispref/markers.texi
+++ b/doc/lispref/markers.texi
@@ -344= ,10 +344,12 @@ specify the insertion type, create them with insertion type<= br> @section Moving Marker Positions
 
   This se= ction describes how to change the position of an existing
-marker.  When you do this, be sure you know whether the marker is use= d
-outside of your program, and, if so, what effects will result from-moving it---otherwise, confusing things may happen in other parts of
-= Emacs.
+marker.  When you do this, be sure you know how the marker is used+outside of your program.  For example, moving a marker to an unrelat= ed
+new position can cause undo to later adjust the marker incorrectly.<= br>+Often when you wish to relocate a marker to an unrelated position, it +is preferable to make a new marker and set the prior one to point
+nowh= ere.
 
 @defun set-marker marker position &optional buf= fer
 This function moves @var{marker} to @var{position}

then= we don't need to worry about markers in general, only the
particular offending ones of the recipe.

As I described, one offendi= ng marker is the mark-marker. From the
push-mark function:

(defun= push-mark (&optional location nomsg activate)
  [...]
 = ;   (setq mark-ring (cons (copy-marker (mark-marker)) mark-ring))=
  [...]
  (set-marker (mark-marker) (or location (point)) (cur= rent-buffer))
  [...]
  (setq global-mark-ring (cons (copy-= marker (mark-marker)) global-mark-ring))
  )

Two copies are = made and the copies go to the mark-ring and
global-mark-ring. The mark continues to be the same marker object
under = eq as before, only mutated. Consequently, not only does undo
adjust a ma= rker it shouldn't have, but it doesn't adjust the copies in
the rings when it should have.

What makes more sense to me is that t= he old value of mark-marker is
pushed onto the rings, then a new marker = object is created to become
the value of mark-marker. Then the marker ad= justment records would
reference the right markers. Effectively this means the mark would
follo= w the advice of the Elisp manual excerpt above.

I welcome your guida= nce about what the right way to solve this bug is.
Thank you.

--089e0115f368f8aea004f32ebc79--