Re: Rename, delete and move current buffer and file

[Stefan Monnier]

> different: for the path you have default-directory, an elisp variable, and

[ Side note: After

      C-x C-f /home/foo/bar

  buffer-file-name should be "/home/foo/bar" and default-directory should
  be "/home/foo/".  But note that if you then do:

      M-x cd RET / RET

  you'll see that default-directory is now "/", i.e. default-directory is
  not actually tied to the name of the buffer's file.

  This said, the two are in-sync 99.9% of the time.
]

> How can we fix or improve those issues?
>
> For rename/delete/move I would create three distinct commands:
> rename-visited-file-with-buffer
> move-visited-file-with-buffer

I don't really know what's the intended difference between "rename" and
"move", but I think rather than introduce new commands (whose name users
won't remember), it'd make more sense to "enhance" existing commands.
E.g. I personally rename/move files usually via

    M-x delete-file RET M-n RET
    C-x C-w <newname> RET

so maybe we could instead have `C-x C-w` prompt the user
"delete the old file (y or n)?"

Similarly

    M-x rename-file RET

could try and detect if the source name matches some of the buffers's
filenames and ask whether we want to rename those buffers's filenames
accordingly.

> delete-visited-file-with-buffer

Hmm... Not sure how best to introduce this behavior into existing commands.

I don't remember being conscious of having such a need, but I think I'd
do it with:

    M-x delete-file RET M-n RET
    C-x C-c

[ I have C-x C-c remapped the kill the current-buffer, since
  I prefer to use `M-x kill-emacs RET` for those rare cases where
  I really want to exit the current Emacs session.  ]

So maybe `delete-file` could ask whether we wants to kill the
corresponding buffers (as for `rename-file` above it's "buffer*S*"
since it can affect several buffers in the case where the
deleted/renamed "file" is actually a directory).

> Those names make the functions easy to discover if you are using something
> like ivy or ido for M-x,

[ Same applies if you use `icomplete-mode` or if you use the
  bog-standard default completion ;-)  ]

> while they are still precise from the standpoint
> of Emacs concepts. It seems good to me to separate rename, which should
> prefill the minibuffer prompt with the current name, and ask only for a new
> filename, WITHOUT directory selection, from move, which should prompt for a
> full new path, WITH directory selection.

C-x C-w gives you "/current/dir/" is initial input.  If you then type
"/other/dir/" it will "move" the file without "renaming" it (I
personally don't like to make this distinction, probably because
I consider the file's name to include all the leading directories, which
is also the implicit point of view of the GNU Coding Standard which uses
"file name" rather than "path" and reserves the word "path" for things
like $PATH, $LS_LIBRARY_PATH, load-path, ...).
And M-n inserts the current name, so I think it handles both
use-cases well enough.

[ For those how like the "default" to be pre-inserted in the buffer
  (and highlighted as the current region so that delete-selection-mode
  will automatically delete it) rather than go through M-n, this should
  be a global user-config option.  ]

> For the current buffers file and directory name, I think aliasing
> default-directory as visited-file-name-directory, and introducing
> visited-file-name is one option. Another option: introduce
> buffer-directory-name as a complement to the existing buffer-file-name
> function. That would cleanup the elisp part, and then at least the names
> are something you can remember, and with M-: you can kill, insert or
> display those.

I thought `M-x pwd RET` was a good enough way to get that info.

> Question remains how to fix those things also on an user interface level. I
> think it's a pity clicking on the filename in the modeline changes the
> current buffer, I am happy to hear if I am mistaken, but today this
> behavior is rather unexpected and I would be very surprised to see somebody
> switching buffers this way.

On the contrary I'd be surprised if noone uses this buffer-switching
system, since it's been around for so many years.  I don't claim it's
the best use of that "button-like thingy", but changing it would
inevitably irk some users.

[ FWIW, I don't use that functionality, but then again, I don't use
  dired either.  ]

> On the other hand it looks like a nice place for a menu where all the
> operations mentioned could be triggered

I guess it could make sense, indeed.

> (rename, move and delete file+buffer, display/kill/insert directory
> name or file name). Providing default key bindings under a common
> prefix for them could be nice too.

A common key-prefix for such file operations would be nice, indeed
(this key-prefix could be considered as a kind of "buffer-less
lightweight dired").


        Stefan