From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Rename, delete and move current buffer and file Date: Mon, 07 May 2018 10:53:31 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1525704710 18537 195.159.176.226 (7 May 2018 14:51:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 7 May 2018 14:51:50 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 07 16:51:45 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fFhUO-0004j9-AL for ged-emacs-devel@m.gmane.org; Mon, 07 May 2018 16:51:44 +0200 Original-Received: from localhost ([::1]:46655 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fFhWV-0005Ub-Ey for ged-emacs-devel@m.gmane.org; Mon, 07 May 2018 10:53:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fFhWO-0005UJ-4Y for emacs-devel@gnu.org; Mon, 07 May 2018 10:53:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fFhWL-0004iI-0P for emacs-devel@gnu.org; Mon, 07 May 2018 10:53:48 -0400 Original-Received: from [195.159.176.226] (port=35274 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fFhWK-0004hD-Oo for emacs-devel@gnu.org; Mon, 07 May 2018 10:53:44 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fFhU6-0004Re-OZ for emacs-devel@gnu.org; Mon, 07 May 2018 16:51:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 127 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:FSmRXInwykXoEI7JloevDQAogos= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225114 Archived-At: > 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 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