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: Thu, 17 Apr 2003 17:39:10 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200304172139.h3HLdBvK009948@rum.cs.yale.edu> References: <200304142022.h3EKMHRu026814@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1050615783 9892 80.91.224.249 (17 Apr 2003 21:43:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 17 Apr 2003 21:43:03 +0000 (UTC) Cc: Stefan Monnier Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 17 23:43:00 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 196H8B-0002Us-00 for ; Thu, 17 Apr 2003 23:41:19 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 196HBB-0002Fo-00 for ; Thu, 17 Apr 2003 23:44:25 +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 196H87-0000Sp-04 for emacs-devel@quimby.gnus.org; Thu, 17 Apr 2003 17:41:15 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 196H7a-0000HN-00 for emacs-devel@gnu.org; Thu, 17 Apr 2003 17:40:42 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 196H6e-0008IS-00 for emacs-devel@gnu.org; Thu, 17 Apr 2003 17:39:47 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 196H67-0007yC-00; Thu, 17 Apr 2003 17:39:11 -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 h3HLdBx6009950; Thu, 17 Apr 2003 17:39:11 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h3HLdBvK009948; Thu, 17 Apr 2003 17:39:11 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Richard Stallman Original-cc: emacs-devel@gnu.org 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:13270 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13270 > Ideas 1, 2 and 3 are good ideas--please install them. Done. People who had ideas for how to improve them or change the defaults should feel free to do it. (except for the :group argument which should be unnecessary) > However, I think that the name with-errors-caught is unnatural; > please call it report-errors. Done. > Please don't change the argument to revert-buffer. > It is intentional that M-x revert-buffer RET asks for confirmation. What is the intention exactly ? The reaosn why I don't understand is that it is not very common for the user to hit M-x revert-buffer RET and the only times I've seen this happen is when the user knows full well the confirmation is going to pop up and she'll answer "yes". > Idea 5 would be nice in principle, but it cannot possibly > work right. There is no way to connect the locations > in the undo list with the new buffer contents correctly. > It would be an arbitrary decision, and the results of undoing > those changes would be nonsensical. Huh? It works just dandy here. The undo-log is correct (and has the necessary entries corresponding to the insert-file operation). The only real issue is not correctness but performance: the undo-log might contain a very large string (if the insert-file operation had to modify a large part of the buffer). > The only case in which this would really work right is when the buffer > text is unchanged. That case may occur often in using VC. Perhaps > you can make insert-file-contents detect it. insert-file-contents > already tries to notice when text at the start of the buffer and/or > text at the end of the buffer are unchanged. It could preserve the > undo list when the stuff to undo is within the unchanged areas > of the text at the beginning or the end. I was wondering if it would be worth it to try and make insert-file even more clever: pass the `before' and `after' to diff and then apply the diff by hand. This will preserve even more of the markers (and would make the undo-log smaller and more useful, in the case that revert-buffer doesn't flush it). Stefan