From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Reverting but keeping undo Date: Tue, 28 May 2013 22:13:12 -0700 (PDT) Message-ID: <92f42e8d-b6a8-4f2e-bd1d-c717f1ea9dd0@default> References: <87mwrwede7.fsf@wanadoo.es> <8738t6tqie.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1369804421 963 80.91.229.3 (29 May 2013 05:13:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 May 2013 05:13:41 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, Stefan Monnier To: Dmitry Gutov Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed May 29 07:13:39 2013 Return-path: Envelope-to: geh-help-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 1UhYhd-0005hh-Qs for geh-help-gnu-emacs@m.gmane.org; Wed, 29 May 2013 07:13:38 +0200 Original-Received: from localhost ([::1]:57601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhYhd-0000Pv-9y for geh-help-gnu-emacs@m.gmane.org; Wed, 29 May 2013 01:13:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhYhO-0000P2-GV for help-gnu-emacs@gnu.org; Wed, 29 May 2013 01:13:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhYhJ-0004cf-Iq for help-gnu-emacs@gnu.org; Wed, 29 May 2013 01:13:22 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:21380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhYhJ-0004a5-BR for help-gnu-emacs@gnu.org; Wed, 29 May 2013 01:13:17 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4T5DC7a024233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 May 2013 05:13:13 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4T5DCVq014461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 May 2013 05:13:13 GMT Original-Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4T5DCmh014453; Wed, 29 May 2013 05:13:12 GMT In-Reply-To: <8738t6tqie.fsf@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:91120 Archived-At: > >> FWIW, I just installed a patch in Emacs's trunk which makes that > >> revert-buffer doesn't discard undo history any more. > > > > Hm. So `revert-buffer' no longer removes undo? That has always been a > > part of what reverting means. And it is clearly intended in the code, > > not just an unfortunate accident or oversight. >=20 > I think it's a great change. > > > And why no discussion beforehand? Yes, why? Any good reason? > > I can't think of a great reason why > > undo should *always* be removed as part of reverting (as it always has > > been). But just maybe there is a good reason for doing that, at least > > some or even most of the time. Why not give Richard et al the benefit > > of the doubt (30 years of "classic" reverting) and make undo removal > > optional, at least for a while? (Or is doubt a no-no?) >=20 > Are you, personally, asking for it to be customizable? Code and users should control whether to get the new behavior or the behavi= or they've had for the last 3 decades. (Sure, users can add back code them= selves to empty the undo list and get back the former behavior...) > What's your use case for throwing away the undo list? That's what reverting is about: returning to an initial state. The undo li= st did not exist when the buffer was first visited - a new buffer has no un= do. Reverting generally means starting over from scratch - i.e., putting t= hings in the same state they had at the outset (since the last save). Yes, there are some exceptions - some buffers have special reverting behavi= or. And yes, we can define Emacs to be anything. We can change what rever= ting means generally in Emacs, if we want. But such a basic change calls f= or a little discussion at emacs-devel, don't you think? Maybe someone wants to keep some highlighting they applied in the buffer to= o, or keep some local variables, or... A similar argument could be made fo= r keeping all sorts of changes to the buffer state after "reversion". But = generally the way to make any such design/behavior change is to first propo= se and discuss in emacs-devel@gnu.org. =20 There might well be someone out there who, "personally" or not (?), has (an= other) good argument for keeping things the way they were - at least as an = option. Who knows? As Richard often says (especially for changes to basic= , longstanding behavior), why not poll the users? Do you "personally" know that no one wants to drop the undo list when rever= ting - whether interactively or in code? Don't you wonder that this came up now seemingly for the first time? Do yo= u think that no one has thought before about whether the undo list should b= e kept or dropped when reverting? A bit presumptuous, no? Give those who designed and first implemented buffers and buffer reverting = the benefit of the doubt, at least to start with. They were not necessaril= y right, but they were not obviously wrong, which is seemingly the way you = look at it. To you it is apparently a no-brainer that undo should not be d= ropped - how silly they were in the old days... Has something changed recently that suddenly makes the original design no l= onger appropriate? What's new here? Facebook? Mobile apps? The Kardashi= ans? Why should this behavior be changed now - why not before? Think about it a bit more. Open it for discussion on emacs-devel. Why act= so precipitously? Is that "personally" necessary?