From: "Jarosław Rzeszótko" <jrzeszotko@gmail.com>
To: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: Rename, delete and move current buffer and file
Date: Mon, 7 May 2018 18:20:26 +0200 [thread overview]
Message-ID: <CAO_X8WDj1W9f7cwMuT0cP9r2mTpLKhM4E0nXJ1z5ynXUnkKVGg@mail.gmail.com> (raw)
In-Reply-To: <jwvbmdrv9dt.fsf-monnier+gmane.emacs.devel@gnu.org>
[-- 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 --]
next prev parent reply other threads:[~2018-05-07 16:20 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-07 13:58 Rename, delete and move current buffer and file Jarosław Rzeszótko
2018-05-07 14:53 ` Stefan Monnier
2018-05-07 16:20 ` Jarosław Rzeszótko [this message]
2018-05-07 17:01 ` Stefan Monnier
2018-05-07 17:47 ` Jarosław Rzeszótko
2018-05-08 1:28 ` Stefan Monnier
2018-05-08 7:05 ` Jarosław Rzeszótko
2018-05-09 12:28 ` Stefan Monnier
2018-05-09 18:12 ` Radon Rosborough
2018-05-09 22:44 ` Stefan Monnier
2018-05-10 17:01 ` Radon Rosborough
2018-05-10 21:49 ` Stefan Monnier
2018-05-11 7:31 ` Andreas Schwab
2018-05-11 15:33 ` Stefan Monnier
2018-05-11 15:45 ` Paul Eggert
2018-05-11 16:06 ` Clément Pit-Claudel
2018-05-11 16:14 ` Stefan Monnier
2018-05-09 23:50 ` Van L
2018-05-10 5:37 ` Jarosław Rzeszótko
2018-05-10 13:18 ` Van L
2018-05-10 8:20 ` Amit Ramon
2018-05-10 8:59 ` Phil Sainty
2018-05-10 16:04 ` Eli Zaretskii
2018-05-07 18:20 ` Andreas Schwab
2018-05-08 1:28 ` Stefan Monnier
2018-05-07 15:28 ` Yuri Khan
2018-05-07 16:20 ` Jarosław Rzeszótko
2018-05-09 11:46 ` Tino Calancha
2018-05-07 15:29 ` Andreas Röhler
2018-05-07 15:38 ` Andreas Röhler
2018-05-10 0:46 ` net june
2018-05-11 6:26 ` Andreas Röhler
2018-05-11 16:10 ` net june
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAO_X8WDj1W9f7cwMuT0cP9r2mTpLKhM4E0nXJ1z5ynXUnkKVGg@mail.gmail.com \
--to=jrzeszotko@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.