From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: rename-file Date: Thu, 27 Aug 2009 16:59:30 +0200 Message-ID: <87iqg9cnfx.fsf@escher.local.home> References: <4A955D32.8030202@gnu.org> <8763ca9zbi.fsf@escher.local.home> <87d46hejn8.fsf@escher.local.home> <878wh5efts.fsf@escher.local.home> <871vmxebsm.fsf@escher.local.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1251385196 5035 80.91.229.12 (27 Aug 2009 14:59:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Aug 2009 14:59:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 27 16:59:50 2009 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 1MggS4-000540-Jq for ged-emacs-devel@m.gmane.org; Thu, 27 Aug 2009 16:59:48 +0200 Original-Received: from localhost ([127.0.0.1]:37956 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MggS4-0005C5-0E for ged-emacs-devel@m.gmane.org; Thu, 27 Aug 2009 10:59:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MggRw-0005At-QZ for emacs-devel@gnu.org; Thu, 27 Aug 2009 10:59:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MggRs-00058L-11 for emacs-devel@gnu.org; Thu, 27 Aug 2009 10:59:40 -0400 Original-Received: from [199.232.76.173] (port=56055 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MggRr-00057x-JT for emacs-devel@gnu.org; Thu, 27 Aug 2009 10:59:35 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:43060) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MggRq-0008Ej-Kr for emacs-devel@gnu.org; Thu, 27 Aug 2009 10:59:35 -0400 Original-Received: (qmail invoked by alias); 27 Aug 2009 14:59:31 -0000 Original-Received: from i59F5518C.versanet.de (EHLO escher.local.home) [89.245.81.140] by mail.gmx.net (mp061) with SMTP; 27 Aug 2009 16:59:31 +0200 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX18KBPA9jsEKTIe/a0ycTw8S/EIIlfrONoM/hKYo+b ydsdLLo/UCkOpE Original-Received: by escher.local.home (Postfix, from userid 1000) id E55981D1848; Thu, 27 Aug 2009 16:59:30 +0200 (CEST) In-Reply-To: (Miles Bader's message of "Thu, 27 Aug 2009 20:50:24 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:114691 Archived-At: On Thu, 27 Aug 2009 20:50:24 +0900 Miles Bader wrote: > Stephen Berman writes: >> I don't understand how anyone can deny that evaluating the variable >> whose value is documented as the "Name of file visited in current >> buffer, or nil if not visiting a file" should return the correct current >> name of the visited file. > > Because "rename-file" is a relatively low-level command, which just > tells the OS to rename the file. > > If you want "smart" renaming, use dired to rename files ("R" command). > It will update buffer filenames (and buffer names) accordingly. > > While the latter behavior is convenient, there's certainly nothing > _wrong_ with the former -- there's no guarantee that a buffer's filename > variable refers an existing file at all (and really there can't be, > since in the general case, emacs can't keep track of what goes on in the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > filesystem behind its back). ^^^^^^^^^^^^^^^^^^^^^^^^^^ I understand the Emacs can't be expected to track filesystem changes that happen outside its purview (but sometimes it does anyway, e.g. auto-revert-mode), but my concern is about changes due to a sequence of Emacs commands (steps 1-4 below), which result in a value for buffer-file-name that to my understanding is not consistent with its doc string. I wouldn't have complained if the doc string had noted this possibility, e.g.: "Name of file visited in current buffer, or nil if not visiting a file. Note that a non-nil value of this variable does not change if the file name changed after visiting the file." On Thu, 27 Aug 2009 14:18:03 +0200 Andreas Schwab wrote: > Stephen Berman writes: > >>>> 1. C-x C-f bla >>>> 2. C-h v buffer-file-name => bla >>>> 3. M-x rename-file RET blabla >>>> 4. C-h v buffer-file-name => bla >>>> >>>> Surely the return value in step 4 is unwanted, isn't it? >>> >>> The visited name of the buffer didn't change in any way whatsoever. >> >> But that's precisely the problem! > > There is no assotiation between a buffer and a file, only between a > buffer and file name. > >>> Only set-visited-file-name can do that. >> >> Then it should be made to take effect between steps 3 and 4 above. > > No. That the filesystem changes does not in any way change the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > association of a buffer to a file name, just like deleting a file does ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > not magically kill a buffer. That appears to depend on the command or function that brings about the filesystem change, e.g. write-file does change the association of a buffer to a file name: 5. C-h v buffer-file-name => blip 6. C-x C-w blap (i.e. at the prompt type "blap" after default-directory) 7. C-h v buffer-file-name => "//blap" 8. There is no longer a buffer visiting "//blip" If write-file does it, there's no reason in principle why rename-file cannot do it, so if (or since) it (currently) does not change the association, the doc string should note this. Or is there a convention that an Emacs command does not track file system changes unless its doc string explicitly says it does? If so, is this convention documented or assumed as common lore? Steve Berman