unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Barry OReilly <gundaetiapo@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 16818@debbugs.gnu.org
Subject: bug#16818: Acknowledgement (Undo in region after markers in undo history relocated)
Date: Mon, 24 Feb 2014 17:46:11 -0500	[thread overview]
Message-ID: <CAFM41H2Q-x8L9jPjUNk=9TJoc3mDz2P19UV0bK1RbZ-25nYQZg@mail.gmail.com> (raw)
In-Reply-To: <jwv1tyyo06q.fsf-monnier+emacsbugs@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

> > 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.

[-- Attachment #2: Type: text/html, Size: 3232 bytes --]

  parent reply	other threads:[~2014-02-24 22:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-19 22:15 bug#16818: Undo in region after markers in undo history relocated Barry OReilly
     [not found] ` <handler.16818.B.13928481719895.ack@debbugs.gnu.org>
2014-02-19 23:07   ` bug#16818: Acknowledgement (Undo in region after markers in undo history relocated) Barry OReilly
2014-02-20  4:53     ` Stefan Monnier
2014-02-20 14:38       ` Barry OReilly
2014-02-24 22:46       ` Barry OReilly [this message]
2014-02-25 21:43         ` Stefan Monnier
2014-02-26 15:18           ` Barry OReilly
2014-03-11 21:24           ` Barry OReilly
2014-03-12 23:24             ` Stefan Monnier
2014-03-13  1:59               ` Barry OReilly
2014-03-13 13:24                 ` Stefan Monnier
2014-03-13 14:35                   ` Stefan Monnier
2014-03-13 16:55                     ` Barry OReilly
2014-03-17 23:05                     ` Barry OReilly
2014-03-18  0:02                       ` Stefan
2014-03-19 13:36                         ` Barry OReilly
2014-03-19 18:52                           ` Stefan
2014-03-19 13:45                         ` Barry OReilly
2014-03-19 18:56                           ` Stefan
2014-03-23 22:49                             ` Barry OReilly
2014-03-24 13:03                               ` Stefan
2014-03-24 22:10                                 ` Barry OReilly
2014-03-25  1:28                                   ` Stefan
2014-03-25  2:32                                     ` Barry OReilly
2020-09-09 12:25                                       ` Lars Ingebrigtsen
2020-12-06 15:57                                         ` bug#16818: Undo in region after markers in undo history relocated Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFM41H2Q-x8L9jPjUNk=9TJoc3mDz2P19UV0bK1RbZ-25nYQZg@mail.gmail.com' \
    --to=gundaetiapo@gmail.com \
    --cc=16818@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).