On Mon, May 7, 2018 at 4:53 PM, Stefan Monnier <address@hidden> wrote:
> 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.
]
That's maybe one more reason a function like buffer-directory-name would be nice? Semantics for all the operations being discussed surely take some thought and maybe trial & error to get right, as is also clear when looking at set-visited-file-name and seeing how it is quite complicated.
> 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.
People might not remember the whole command name, but when they use M-x, or C-h f with some filtering it will pop up when typing "rename" or "move", which is what those operations are now called pretty universally in other programs. It's easily discoverable this way, and you might key bind if you want, while renaming via delete-file is something that you might figure out but not necessarily anything close to the first thing you would try. So I stand by my commands proposal. As mentioned I also hope there are ways to integrate it into keybindings and UI, maybe also a manual section for such not-dired file operations would be nice. I think those are basic things people want to do, and a bit of a gap in the basic set of Emacs functionalities.
The difference between "rename" and "move" I intended was for rename to mean changing the filename (without moving to another directory), and for move to mean moving to another directory, keeping or also changing the filename. You can present slightly different prompt/completion in the minibuffer for the two cases, which I thought might make for a nice UX. I would also be fine with just a "move" command, which lets you do both things, see below.
> 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.
This creates a copy of the file, while I want to rename/move it. This might include things like deal with version control. A single "move" function is fine, maybe even the set-visited-file-name semantics are OK, it just has a bad name, has no key bindings, no menu item, and I would like a delete-visited-file to complement it. When I look for a command to move a file in the M-x completion prompt, I will try "move" and "rename" and see what matches, but I would surely not naturally come up with any substring of set-visited-file-name when thinking how Emacs might have named a command to move files, except for "file-name", but this matches a ton of things. I am sure many people using Emacs don't even know the concept of a visited file.
Also, note there is rename-file, rename-buffer, but then set-visited-file-name for what is effectively rename-file-with-visited-buffer. There is also an interactive delete-file, obviously there is kill-buffer, but no way to delete file and kill its visiting buffer. I just hope maybe we can find some way to make this more uniform and complete.