From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: find-file for file that was deleted, when visiting buffer still exists Date: Sat, 3 Mar 2007 09:29:49 -0800 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1172943108 15512 80.91.229.12 (3 Mar 2007 17:31:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2007 17:31:48 +0000 (UTC) To: "Emacs-Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 03 18:31:42 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HNY55-0006xu-Ae for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 18:31:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNY54-0007oz-S4 for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 12:31:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNY4s-0007oj-Ms for emacs-devel@gnu.org; Sat, 03 Mar 2007 12:31:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNY4q-0007oD-6G for emacs-devel@gnu.org; Sat, 03 Mar 2007 12:31:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNY4q-0007oA-1u for emacs-devel@gnu.org; Sat, 03 Mar 2007 12:31:24 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HNY4p-0000Xc-LX for emacs-devel@gnu.org; Sat, 03 Mar 2007 12:31:23 -0500 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l23HVKpr006212 for ; Sat, 3 Mar 2007 10:31:21 -0700 Original-Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l23HUpqv022233 for ; Sat, 3 Mar 2007 10:31:20 -0700 Original-Received: from dhcp-amer-csvpn-gw2-141-144-73-90.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 2493410691172942992; Sat, 03 Mar 2007 10:29:52 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:67261 Archived-At: This has been standard Emacs behavior for a long time, but I wonder about it. 1. Visit a file `foo' in a buffer. Close the window, but don't kill the buffer. 2. Delete file `foo' (e.g. `delete-file' or some other way that doesn't also kill the buffer). 3. `C-x C-f foo' This raises an error saying that the file no longer exists. [The error message says nothing about the existing buffer, BTW. If a user forgets that the buffer still exists, then s?he might have a difficult time understanding this message and why s?he can't use `C-x C-f' to create a new file named `foo'.] I wonder if this is really what Emacs should always do in this context. IIUC, the real problem is that the buffer still exists, and Emacs can't know what the user wants to do in this case. S?he might want to save the buffer. S?he might want to kill the buffer and create a new file-visiting buffer with the same name. There are perhaps additional possibilities. This error is raised by `find-file-noselect', which is not a command, so not much is known about the user context at this point - the function might even be run in batch. IOW, the error is raised at a fairly low level, in a function that is called in many different ways. I wonder if it wouldn't be good to try to deal with the interactive cases by asking the user what to do. That is, try to handle the error by passing it up to the command (`find-file' etc.) whenever the command is called interactively. Perhaps a dialog something like this: Buffer `foo' was visiting file `foo', which no longer exists. Choose one: s RET - Save buffer `foo' as file `foo' k RET - Visit a new, empty file in buffer `foo' RET - Do nothing WDOT? Am I missing something important that argues for the current behavior even for interactive use? If my suggestion is a bad idea, can we at least improve the error message, so that it mentions the existing buffer?