Re: Rename, delete and move current buffer and file

["Jarosław Rzeszótko" <jrzeszotko@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5801 bytes --]

On Mon, May 7, 2018 at 4:53 PM, Stefan Monnier <monnier@iro.umontreal.ca>
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.

[-- Attachment #2: Type: text/html, Size: 12574 bytes --]