From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?SmFyb3PFgmF3IFJ6ZXN6w7N0a28=?= Newsgroups: gmane.emacs.devel Subject: Re: Rename, delete and move current buffer and file Date: Mon, 7 May 2018 18:20:26 +0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000337816056ba00c03" X-Trace: blaine.gmane.org 1525709995 21186 195.159.176.226 (7 May 2018 16:19:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 7 May 2018 16:19:55 +0000 (UTC) To: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 07 18:19:51 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 1fFirc-0005Lt-Lr for ged-emacs-devel@m.gmane.org; Mon, 07 May 2018 18:19:49 +0200 Original-Received: from localhost ([::1]:47094 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fFitj-0002wk-Ne for ged-emacs-devel@m.gmane.org; Mon, 07 May 2018 12:21:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fFisI-0002Dl-Jt for emacs-devel@gnu.org; Mon, 07 May 2018 12:20:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fFisG-0006Wb-7u for emacs-devel@gnu.org; Mon, 07 May 2018 12:20:30 -0400 Original-Received: from mail-yw0-x232.google.com ([2607:f8b0:4002:c05::232]:35886) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fFisG-0006WN-1H for emacs-devel@gnu.org; Mon, 07 May 2018 12:20:28 -0400 Original-Received: by mail-yw0-x232.google.com with SMTP id l15-v6so8771906ywk.3 for ; Mon, 07 May 2018 09:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=t8Hm3rRJUPHX00LJ9lvxZWJQdYhxQ1sugAsDzd0lQls=; b=Q8TZr606sWbcrKe6YBTgV5/2EGGhkxFG6wySUA/iTlI7khT9tV8jGY8KxuuIINJiIu ggmN1cJOijGyL74NbPUfDszCKsIQeVwHWovIPH/jkrwL1XkT2J9UaSbk3SQgm9TsdIAI nnrhwA0PYjGVUEXwqyvGDh31ng4nZFQBs1BcGVDdMqw/3a+DXSa+ff7QxDB7SZNETmIm sPTn/WABhknAmzkIa9+9luXifGS1zOl6LkSEU14LP1GKF9fKcjlStG7x0/AvK8zdLuL3 J+kJXNx+aU3/1i4fa3z33uRH7AybOuoRg6agbUA/Vi5gO7pCvWzp7nL4+2nSDbrABw/T B6BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=t8Hm3rRJUPHX00LJ9lvxZWJQdYhxQ1sugAsDzd0lQls=; b=qyB5hHPs2TNJdHhLtjev/nn+MiQp0JNDIU71RFx9ASgEHiA5ycUgQ0V00qlyKtON8P /seGuJ9dbI1SRQwAo9fGGprGH99/dq79XXV/A5NvWlz5RvIQaFoKG0SzLNsJ+IH9zDG2 kP3RhODpQiXmjmugfPZnoBgDSpxGy8xfPG61q6P46zbazrUEKeOMVZ9tWBILJkIK1HXX fH8SXHOZjpN1z0hvQpBbUZEYs+2/6RLfoOwzK2HWKtN0Z5K2JCDwuKGnTrujqHZPv3a6 ocXwdEiwMDtxRH/htcUQ3K0jeMcll5lLPuDc2LacGbaWChwxZaR5krmg3Rhpu3J4ZvIT NNpw== X-Gm-Message-State: ALQs6tB2eipJYorljMo36SSUktb0f8OTk6kG7NCuJaQqZezmMdUSHxHn RvQAYLVX0MY2/lerlVKxKt0Kw3mClU7XNM9H1agHrg== X-Google-Smtp-Source: AB8JxZp0TFpHZWE79Q5YTw8+VHZik3PhFFB160nSFlEoCb0uF8rAns5qUVWSMhDJ9O9ZtI0XynlDbngxJmYzh+AVlYo= X-Received: by 2002:a81:8413:: with SMTP id u19-v6mr21364215ywf.487.1525710027190; Mon, 07 May 2018 09:20:27 -0700 (PDT) Original-Received: by 2002:a5b:b08:0:0:0:0:0 with HTTP; Mon, 7 May 2018 09:20:26 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4002:c05::232 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:225119 Archived-At: --000000000000337816056ba00c03 Content-Type: text/plain; charset="UTF-8" On Mon, May 7, 2018 at 4:53 PM, Stefan Monnier 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 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. --000000000000337816056ba00c03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 7, 2018 at 4:53 PM, Stefan = Monnier=C2=A0<monnier@i= ro.umontreal.ca>=C2=A0wrote:
> different: for the path you ha= ve default-directory, an elisp variable, and

[ Side note: Aft= er

=C2=A0 =C2=A0 =C2=A0 C-x C-f /home/foo/bar

=C2=A0 buffer-f= ile-name should be "/home/foo/bar" and default-directory should=C2=A0 be "/home/foo/".=C2=A0 But note that if you then do:
=
=C2=A0 =C2=A0 =C2=A0 M-x cd RET / RET

=C2=A0 you'll see that= default-directory is now "/", i.e. default-directory is
=C2= =A0 not actually tied to the name of the buffer's file.

=C2=A0 T= his said, the two are in-sync 99.9% of the time.
]
=
That's maybe one more reason a function like buffer-di= rectory-name would be nice? Semantics for all the operations being discusse= d 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.
=C2=A0

> How can we fix or improve thos= e issues?
>
> For rename/delete/move I would create three disti= nct commands:
> rename-visited-file-with-buffer
> move-vis= ited-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 command= s.
E.g. I personally rename/move files usually via

=C2=A0 =C2=A0 = M-x delete-file RET M-n RET
=C2=A0 =C2=A0 C-x C-w <newname> RET
so maybe we could instead have `C-x C-w` prompt the user
"dele= te the old file (y or n)?"

Similarly

=C2=A0 =C2=A0 M-x r= ename-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 b= uffers'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 u= niversally in other programs. It's easily discoverable this way, and yo= u might key bind if you want, while renaming via delete-file is something t= hat you might figure out but not necessarily anything close to the first th= ing 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 m= anual section for such not-dired file operations would be nice. I think tho= se are basic things people want to do, and a bit of a gap in the basic set = of Emacs functionalities.

The difference between "r= ename" and "move" I intended was for rename to mean changing= the filename (without moving to another directory), and for move to mean m= oving 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.<= /div>
=C2=A0

> delete-visit= ed-file-with-buffer

Hmm... Not sure how best to introduce this = behavior into existing commands.

I don't remember being consciou= s of having such a need, but I think I'd
do it with:

=C2=A0 = =C2=A0 M-x delete-file RET M-n RET
=C2=A0 =C2=A0 C-x C-c

[ I have= C-x C-c remapped the kill the current-buffer, since
=C2=A0 I prefer to = use `M-x kill-emacs RET` for those rare cases where
=C2=A0 I really want= to exit the current Emacs session.=C2=A0 ]

So maybe `delete-file` c= ould ask whether we wants to kill the
corresponding buffers (as for `ren= ame-file` above it's "buffer*S*"
since it can affect sever= al buffers in the case where the
deleted/renamed "file" is act= ually a directory).

> Those names make the functions easy t= o discover if you are using something
> like ivy or ido for M-x,
<= br>[ Same applies if you use `icomplete-mode` or if you use the
= =C2=A0 bog-standard default completion ;-)=C2=A0 ]

> while = they are still precise from the standpoint
> of Emacs concepts. It se= ems good to me to separate rename, which should
> prefill the minibuf= fer prompt with the current name, and ask only for a new
> filename, = WITHOUT directory selection, from move, which should prompt for a
> f= ull new path, WITH directory selection.

C-x C-w gives you &qu= ot;/current/dir/" is initial input.=C2=A0 If you then type
"/o= ther/dir/" it will "move" the file without "renaming&qu= ot; it (I
personally don't like to make this distinction, probably b= ecause
I consider the file's name to include all the leading directo= ries, which
is also the implicit point of view of the GNU Coding Standar= d which uses
"file name" rather than "path" and rese= rves 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" f= unction 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 f= ile in the M-x completion prompt, I will try "move" and "ren= ame" and see what matches, but I would surely not naturally come up wi= th any substring of set-visited-file-name when thinking how Emacs might hav= e named a command to move files, except for "file-name", but this= matches a ton of things.=C2=A0I am sure many peo= ple using Emacs don't even know the concept of a visited file.

Al= so, note there is rename-file, rename-buffer, but then set-visited-file-nam= e for what is effectively rename-file-with-visited-buffer. There is al= so an interactive delete-file, obviously there is kill-buffer, but no way t= o delete file and kill its visiting buffer. I just hope maybe we can find s= ome way to make this more uniform and complete.=C2=A0

--000000000000337816056ba00c03--