From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Kifer Newsgroups: gmane.emacs.bugs Subject: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14 Date: Wed, 1 Jun 2016 18:34:05 -0400 Message-ID: <574F62DD.4000506@cs.stonybrook.edu> References: <83vb2h6lfq.fsf@gnu.org> <83r3d56jrg.fsf@gnu.org> <87poso7nf5.fsf@russet.org.uk> <878tzatbte.fsf@russet.org.uk> <877fe85z1e.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1464820526 21868 80.91.229.3 (1 Jun 2016 22:35:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Jun 2016 22:35:26 +0000 (UTC) Cc: 22295@debbugs.gnu.org, Jim Meyering To: Phillip Lord , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 02 00:35:16 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 1b8EjK-0005Oh-1y for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jun 2016 00:35:14 +0200 Original-Received: from localhost ([::1]:44398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8EjI-0004WA-22 for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Jun 2016 18:35:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8EjC-0004UO-Id for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2016 18:35:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8Ej8-0006RG-9F for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2016 18:35:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8Ej8-0006R8-6K for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2016 18:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b8Ej8-0003Jx-0s for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2016 18:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Kifer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Jun 2016 22:35:01 +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.146482045412707 (code B ref 22295); Wed, 01 Jun 2016 22:35:01 +0000 Original-Received: (at 22295) by debbugs.gnu.org; 1 Jun 2016 22:34:14 +0000 Original-Received: from localhost ([127.0.0.1]:50241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b8EiM-0003It-10 for submit@debbugs.gnu.org; Wed, 01 Jun 2016 18:34:14 -0400 Original-Received: from mail-qg0-f53.google.com ([209.85.192.53]:36751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b8EiJ-0003Ig-QU for 22295@debbugs.gnu.org; Wed, 01 Jun 2016 18:34:12 -0400 Original-Received: by mail-qg0-f53.google.com with SMTP id q32so115632611qgq.3 for <22295@debbugs.gnu.org>; Wed, 01 Jun 2016 15:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs-stonybrook-edu.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=2zwx3PhkErX39z7wPQng0pvugVFcPBhAkI3R1FflCzI=; b=KKyfMCr874sNGBG046HTNN+BBSEnEdgSltR+F0HbVwd5KR/amFJte7DUc5DVy9TdME IQkMEEZum6WO/Gas9zv9ms1MMcQb0Xp77B06SY4oqX+K2SLmr1q1rpfPLuOcJL4SpGOZ Eab0UT4LSt/vnJODJ4ihLCEHokCHRu71RzIjLbbPm7x8j2az7yiL1RIaN2UrJ2yjUyYg KIZBM8y2GJF88g6U0PovN6RpOk9Esi2Dk/O9RdWPLC0XZ3vDcHCspsvIcT9KPfQN+WsL 8TKKH3FFC85iJIY4qxZa+dSouJKpORxuo+GY6EL2r6/QYXa7qvOY2nHqNWe/ZMsp2YY/ EVXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2zwx3PhkErX39z7wPQng0pvugVFcPBhAkI3R1FflCzI=; b=NQOFB9PVjNaIcL1oM6Ncj9lQSZMwvuZ0HsF0emkUdejfQ0HYk2BOJlZ6DO05ZXq0xl pt2qC5f7dSB4u3NXBNfUQ3i7Faw/IOo5QZarLcTzRrfJlPuc1shJhocYxC7szEMlSRQd ixpkY4i1xjXU/nQYVtsW0xqADC0+W8t20RzlbcjvLvb8HE3YEcxekiwID/snplzT12hX 31GT2dwC6m8XfQZz7QKfHvPBFWJXkSnv3UvXFqjLxMi+0B2djl41MG5u0NSU+Crr+6Fy Ed5X+sjWeBlyVdfhSzdkUsSmcNa3b8p6U6gbVwspl6Ahho1btAUycAYOwJ6r1NX6Q5MU 64Pg== X-Gm-Message-State: ALyK8tLpMU5CWcUlFi5tpM1MlHNzZBv+JgSThnMzWcYmCSY3qBioq4u9B8UuxR25N55HfXb8 X-Received: by 10.140.29.9 with SMTP id a9mr38301152qga.37.1464820446082; Wed, 01 Jun 2016 15:34:06 -0700 (PDT) Original-Received: from [192.168.1.106] (ool-18ba1846.dyn.optonline.net. [24.186.24.70]) by smtp.gmail.com with ESMTPSA id r64sm4140568qkl.49.2016.06.01.15.34.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 15:34:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 In-Reply-To: <877fe85z1e.fsf@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:118958 Archived-At: On 06/01/2016 06:23 PM, Phillip Lord wrote: > 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 not in 25.0.50 viper worked fine with this for 20 years and I'd say it is Emacs breakage, not Viper's. > 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. Do you know who made the changes to the emacs undo list? Maybe complain to him? > >> Have we been able to identify the original problem? > No, fraid not. Thought about it lots. Failed. could not understand what happened either. -- --- michael > >> 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