On Mon, May 7, 2018 at 7:01 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 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",
[...]
> So I stand by my commands proposal.

I don't understand: it seems like "rename-file" is a name which should
just work with your M-x and C-h f examples, so I don't see how those examples
argues in favor of "my commands proposal" instead of using "rename-file".

I have a file open in a buffer in front of me. I want to rename this file and have the buffer be changed accordingly: it should now be visiting the file under the new name. 

rename-file will instead:
- rename the file but do nothing with the buffer, if I now save the buffer it will get saved under the old file name. The buffer still visits the file under the old name.
- it will also first prompt for a file to rename, while I want to rename the file I am currently editing in a buffer, along with the buffer.

Emacs distinguishing so strongly between buffer and visited file is why people commonly implement something they typically name rename-file-and-buffer, for example:

https://stackoverflow.com/questions/384284/how-do-i-rename-an-open-file-in-emacs
http://emacsredux.com/blog/2013/05/04/rename-file-and-buffer/
http://rejeep.github.io/emacs/elisp/2010/03/26/rename-file-and-buffer-in-emacs.html

But rename-file-and-buffer acting on the current buffers file is inconsistent with rename-file first prompting for a file to rename, hence the logical way would be to have a new set of functions with some shared suffix.
 

>> 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.

I only presented this example to illustrate how Emacs merges both "new
name" and "new directory" into a single UI (tho indeed currently
C-x C-w doesn't actually "move/rename" but it copies instead).

OK, I am completely fine with a single combined move/rename, no disagreement here.
 

> 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,

C-x C-w does have all those feature (other than the name).

> and I would like a delete-visited-file to complement it.

Could you give details as to why you'd want to separate it from
`delete-file`?

Like rename-file, delete-file will prompt for a file to delete, and it will do nothing to a buffer visiting the file, rather than getting rid of the *current* buffer and the file it visits. I often decide to delete the file after I have opened it and viewed it, it seems too much to retype the filename to delete 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,

Right, and you'll find `rename-file`, which is what I think should do
what you want.

> 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.

Agreed.  So I find it odd that you insist on having "visited-file" in
the name of the commands ;-)

That's because there are existing functions that end with -file that act on files but disregard any existing buffers associated with the file. In addition to those existing file functions, and to functions that act on buffers, I was thinking of having a third parallel set of functions that acts on the current buffer and its associated file, and I would like the naming to somehow be consistent between the three groups, that's why I came up with the -buffer-and-visited-file suffix. If that doesn't ring right, maybe it should be something like -current-buffer-and-file instead. Maybe it should actually be four groups:

*-file functions
*-buffer
*-buffer-with-file
*-current-buffer-with-file

Since it's just move/rename and delete/kill, it's just 8 functions, 4 of which already exist. You might not want to do this everyday, but it's also not an exotic use case, again as evidenced by how many times I have seen it discussed on the web and in people's .emacs files. rename-buffer-with-file and delete-buffer-with-file might be useful for programmatic usage via emacs-lisp as well.
 

> Also, note there is rename-file, rename-buffer, but then
> set-visited-file-name for what is effectively
> rename-file-with-visited-buffer.

set-visited-file-name does not rename any file, AFAIK (and I don't see
any suggestion to change this).

If you set the along-with-file argument to t, or use prefix argument, I think it executes a rename like the one I would like to be able to do, so file+buffer.
 

> There is also an interactive delete-file, obviously there is kill-buffer,
> but no way to delete file and kill its visiting buffer.

FWIW, I very rarely need to do delete-file and kill-buffer at the same
time, so I'm not convinced there's a need for a separate command for
that.  But as noted, I'd be OK for delete-file to kill the matching
buffer(s) [ either subject to a prompt or a user-config, for those users
who like to `delete-file` while keeping the buffer, as is occasionally
my case.  ] 

delete-file and rename-file prompting whether to do the corresponding action also on the buffer makes sense in general, better yet if it would be possible to configure Emacs to do this always, by default, when using the functions interactively. Is something like that safe with regards to backward compatibility?

Those act on a file you have to select though, I would like something that specifically acts on the current buffer and its visited file.

Cheers,
Jarosław Rzeszótko