From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.bugs Subject: bug#16818: Acknowledgement (Undo in region after markers in undo history relocated) Date: Mon, 24 Mar 2014 09:03:50 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395668920 10245 80.91.229.3 (24 Mar 2014 13:48:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Mar 2014 13:48:40 +0000 (UTC) Cc: 16818@debbugs.gnu.org To: Barry OReilly Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 24 14:48:46 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 1WS5F0-0006rj-NU for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Mar 2014 14:48:38 +0100 Original-Received: from localhost ([::1]:36437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS5F0-0000R6-AE for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Mar 2014 09:48:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS5E9-0006fn-Tt for bug-gnu-emacs@gnu.org; Mon, 24 Mar 2014 09:47:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WS5AN-0007rM-M8 for bug-gnu-emacs@gnu.org; Mon, 24 Mar 2014 09:43:59 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS4Xq-0005c3-Fe for bug-gnu-emacs@gnu.org; Mon, 24 Mar 2014 09:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WS4Xq-0001Rf-1q for bug-gnu-emacs@gnu.org; Mon, 24 Mar 2014 09:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Mar 2014 13:04:01 +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.13956662355543 (code B ref 16818); Mon, 24 Mar 2014 13:04:01 +0000 Original-Received: (at 16818) by debbugs.gnu.org; 24 Mar 2014 13:03:55 +0000 Original-Received: from localhost ([127.0.0.1]:46787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WS4Xi-0001RL-UT for submit@debbugs.gnu.org; Mon, 24 Mar 2014 09:03:55 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:54659) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WS4Xg-0001RB-IS for 16818@debbugs.gnu.org; Mon, 24 Mar 2014 09:03:53 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s2OD48FZ026700; Mon, 24 Mar 2014 09:04:08 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4AF55600A2; Mon, 24 Mar 2014 09:03:50 -0400 (EDT) In-Reply-To: (Barry OReilly's message of "Sun, 23 Mar 2014 18:49:32 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered NOFROM_SGMAIL=0.2, RV4891=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4891> : inlines <634> : streams <1143843> : uri <1708516> 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:87303 Archived-At: > Attached is the new patch to solve this, implementing option 2 and > incorporating your feedback. Looks good, thank you very much. Feel free to install into emacs-24, but please see my comments below. Stefan > +2014-03-13 Barry O'Reilly > + * markers.texi (Moving Marker Positions): The 2014-03-02 doc Missing empty line between the two. > + (while (and (consp (car list)) > + (markerp (caar list)) (markerp (car-safe (car list))) > + (and (eq (marker-buffer (caar list)) > + (current-buffer)) > + (integerp (marker-position (caar list))) I think this `integerp' test is redundant (marker-position can only return nil or an integer and if it returns nil, then marker-buffer also returns nil). > ;; (MARKER . OFFSET) means a marker MARKER was adjusted by OFFSET. > (`(,(and marker (pred markerp)) . ,(and offset (pred integerp))) > - (when (marker-buffer marker) > - (set-marker marker > - (- marker offset) > - (marker-buffer marker)))) > + (warn "Encountered %S entry in undo list with no matching (TEXT . POS) entry" > + next)) I think I'd add the warning without removing the `set-marker', just to be conservative. > + (when (and (consp undo-elt) > + (stringp (car undo-elt)) (stringp (car-safe undo-elt)) > + (integerp (cdr undo-elt))) > + (let ((list-i (cdr undo-list-copy))) > + (while (markerp (caar list-i)) I think you need (markerp (car-safe (car list-i))) because (car list-i) may be an integer. Also, I'd try to avoid repeatedly calling (car list-i) in the body of the `while' loop(s) by let-binding it. I'd probably do it via `pop', as in (while (...) (let ((elem (pop undo-list))) ...)) > ((and (consp undo-elt) (markerp (car undo-elt))) > - ;; This is a marker-adjustment element (MARKER . ADJUSTMENT). > - ;; See if MARKER is inside the region. > - (let ((alist-elt (assq (car undo-elt) undo-adjusted-markers))) > - (unless alist-elt > - (setq alist-elt (cons (car undo-elt) > - (marker-position (car undo-elt)))) > - (setq undo-adjusted-markers > - (cons alist-elt undo-adjusted-markers))) > - (and (cdr alist-elt) > - (>= (cdr alist-elt) start) > - (<= (cdr alist-elt) end)))) > + ;; (MARKER . ADJUSTMENT) > + nil) It would also be more conservative to keep this unchanged, but I think I agree with you here that we don't need to be *that* conservative. > - record_delete (beg, make_buffer_string (beg, beg + length, 1)); > + record_delete (beg, make_buffer_string (beg, beg + length, 1), false); Begs the question: why didn't (don't) we record marker adjustments here (and other similar places)? Stefan