From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.bugs Subject: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14 Date: Wed, 01 Jun 2016 23:23:25 +0100 Message-ID: <877fe85z1e.fsf@russet.org.uk> References: <83vb2h6lfq.fsf@gnu.org> <83r3d56jrg.fsf@gnu.org> <87poso7nf5.fsf@russet.org.uk> <878tzatbte.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1464819869 12505 80.91.229.3 (1 Jun 2016 22:24:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Jun 2016 22:24:29 +0000 (UTC) Cc: 22295@debbugs.gnu.org, Jim Meyering , Michael Kifer To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 02 00:24:17 2016 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 1b8EYi-000665-8f for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jun 2016 00:24:17 +0200 Original-Received: from localhost ([::1]:44377 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8EYh-0003kM-BH for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Jun 2016 18:24:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8EYZ-0003iM-M9 for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2016 18:24:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8EYU-0001cx-IS for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2016 18:24:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8EYU-0001cR-Bb for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2016 18:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b8EYU-00034B-6P for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2016 18:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: phillip.lord@russet.org.uk (Phillip Lord) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Jun 2016 22:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22295 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22295-submit@debbugs.gnu.org id=B22295.146481981511751 (code B ref 22295); Wed, 01 Jun 2016 22:24:02 +0000 Original-Received: (at 22295) by debbugs.gnu.org; 1 Jun 2016 22:23:35 +0000 Original-Received: from localhost ([127.0.0.1]:50227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b8EY3-00033T-3a for submit@debbugs.gnu.org; Wed, 01 Jun 2016 18:23:35 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:33683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b8EY1-00033F-2Y for 22295@debbugs.gnu.org; Wed, 01 Jun 2016 18:23:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=iHhTvKDOKoZdGNrTJjj+XuMvc2QTjvfK3/Z2wIvj/d0=; b=kGkdzjwPuE7WbXRVxVU7PjCGws 1bSyEud3ZVvb2IdfzbVMTvA5maFw69miF1SK0ehm+kDKYHk3lJ+OVMtm68QBbxCXyXShpQLzAq83l 9sW9Agx+wEvQcBzT7Amr5XsCdjEIyw8QNFVFmsEscReb9SZmaa33y4rBbjIBj6YMC0kI4x6swZfLY 1Ti96/mhuCbEFTOgaPLOBFj8ls5LUMIQpAQo7Nq/j4TjEur6VyBnrWlMDdDjnYoKJp/T60bLehW2G Onjt9KorQc7gYUvdx5H/9bhRsQ+5bOKNyXEKAu8OZ5LIkD3YmaV9lIuh31EUoIlBQWKnfmvV2jG/D G6VoLbEQ==; Original-Received: from cpc1-benw10-2-0-cust373.gate.cable.virginm.net ([77.98.219.118]:53671 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1b8EXu-003z3Y-9N; Wed, 01 Jun 2016 23:23:26 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 01 Jun 2016 09:06:11 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.94 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:118957 Archived-At: Stefan Monnier writes: >> different, though. With this fix, viper just disables automatic boundary >> addition and adds it's own as necessary, which seems cleaner. > > I see an annoying side-effect of that change, tho: > > % emacs -Q -f viper-mode > y 5 n ;; To get past viper's initial questions. > i helo C-b k C-/ > > This last C-/ used to (and should) just undo the insertion of the last > "k", but instead it now completely wipes out the *scratch* buffer. > > So I think that completely disabling undo boundaries is not a good idea: > while in many use-cases insertion mode is very transient, it is not so > unusual to spend more time in insertion mode (which is pretty much > "emacs mode") and to expect undo boundaries to properly inserted during > this time. Oh dear. Yes, that is a problem. The difficulty is that viper modifies the undo-list, removing boundaries only *after* we leave insert mode. Hence, when you type C-/ above they are still there. If you do i helo C-b k escape C-/ before the undo changes, then the whole buffer is deleted also. So, undo behaves different in insert mode and in command mode. Viper's solution of introducing a 'viper symbol is a nice one, but has it's problems. If you do, for example i helo C-b k C-/ C-/ We get an error from the undo system. primitive-undo: Unrecognized entry in undo list viper The deep problem here is that undo boundary == nil -- i.e. there is one and only one symbol for undo-boundary. If it could carry a value, viper could do this cleanly. Only solution that leaps to mind is this: 1) Restore all the old viper code 2) Instead of adding a 'viper mark, copy the buffer-undo-list to "viper-old-buffer-undo-list". 3) Instead of this.... (if (setq tmp (memq viper-buffer-undo-list-mark buffer-undo-list)) we should now already have the cons cell that represents the tail of the buffer-undo-list. This is also quite a big change, and I worry about buffer compaction -- viper-old-buffer-undo-list would not be open for GC. > Have we been able to identify the original problem? No, fraid not. Thought about it lots. Failed. > The old code seemed "simple" enough that the problem was probably > simple to fix (once identified). Well, most problems are simple to fix once you actually know what they are. I shall look again at the old code, and see if I can figure it out. Phil