From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: 4 minor suggestions for files.el Date: Tue, 29 Apr 2003 17:07:20 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200304292107.h3TL7Kl9007427@rum.cs.yale.edu> References: <200304142022.h3EKMHRu026814@rum.cs.yale.edu> <200304172139.h3HLdBvK009948@rum.cs.yale.edu> <1050672259.633.14.camel@localhost> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1051650814 4516 80.91.224.249 (29 Apr 2003 21:13:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 29 Apr 2003 21:13:34 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Apr 29 23:13:32 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19AcPs-0001Aa-00 for ; Tue, 29 Apr 2003 23:13:32 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19AcYh-0005xP-00 for ; Tue, 29 Apr 2003 23:22:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19AcNX-0000L2-02 for emacs-devel@quimby.gnus.org; Tue, 29 Apr 2003 17:11:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19AcLd-0007zg-00 for emacs-devel@gnu.org; Tue, 29 Apr 2003 17:09:09 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19AcLC-0007UC-00 for emacs-devel@gnu.org; Tue, 29 Apr 2003 17:08:43 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19AcJs-0006Ud-00; Tue, 29 Apr 2003 17:07:20 -0400 Original-Received: from rum.cs.yale.edu (localhost [127.0.0.1]) by rum.cs.yale.edu (8.12.8/8.12.8) with ESMTP id h3TL7Kx6007429; Tue, 29 Apr 2003 17:07:20 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h3TL7Kl9007427; Tue, 29 Apr 2003 17:07:20 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Richard Stallman Original-cc: Andre Spiegel Original-cc: monnier+gnu/emacs@rum.cs.yale.edu X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13560 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13560 > VC does a revert-buffer after each version control operation, so that > changes in version headers are picked up. > > If I understand correctly, the revert-buffer would be undoable. > > I think that is what he is proposing. > > I think that is a misguided feature. It is not right to undo > the revert-buffer unless you can undo the whole VC operation with it. Why? Especially with `undo-in-region' it doesn't make sense to undo the operation when only part of the revert is undone (or as is more often the case for me: when only changes prior to the revert are undone). > But that, if we can implement it, must be a VC operation; > M-x undo should not be able to do it. I don't see why not. Just like we can undo changes that were saved with C-x C-s, it makes perfect sense to undo changes that were made by a "minor" revert-buffer (my patch defines "minor" as "which preserves minor-modes"). > I think that the correct way for check-in and update to interact with > M-x undo is to transpose the old undo list somehow to the buffer as it > has been updated. That's what undo-in-region does. > If I edit the buffer and then do an RCS check-in, and the check-in > updates an RCS header in the file, and then I undo, this should not > undo the change in the RCS header. Rather, it should undo the change > that I made manually before the check-in. Just because there's one case where care might be needed, we shouldn't prevent people for whom this doesn't apply to benefit from more flexibility. > Likewise, if I edit the buffer and then do a CVS update, I should > then be able to undo the edit I made, but not the changes made by > the CVS update. Why not ? Stefan