Re: rename-file

[Stephen Berman <stephen.berman@gmx.net>]

On Thu, 27 Aug 2009 20:50:24 +0900 Miles Bader <miles@gnu.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> 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 <schwab@linux-m68k.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> 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 => "/<default-directory>/blap"
8. There is no longer a buffer visiting "/<default-directory>/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