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 19:47:15 +0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b8bc19056ba142aa" X-Trace: blaine.gmane.org 1525715124 333 195.159.176.226 (7 May 2018 17:45:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 7 May 2018 17:45:24 +0000 (UTC) To: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 07 19:45:20 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 1fFkCN-0008R5-Cj for ged-emacs-devel@m.gmane.org; Mon, 07 May 2018 19:45:19 +0200 Original-Received: from localhost ([::1]:47408 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fFkEU-0008Nt-GF for ged-emacs-devel@m.gmane.org; Mon, 07 May 2018 13:47:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fFkEK-0008NV-I4 for emacs-devel@gnu.org; Mon, 07 May 2018 13:47:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fFkEI-0002wB-4J for emacs-devel@gnu.org; Mon, 07 May 2018 13:47:20 -0400 Original-Received: from mail-yw0-x22c.google.com ([2607:f8b0:4002:c05::22c]:34509) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fFkEH-0002vc-TL for emacs-devel@gnu.org; Mon, 07 May 2018 13:47:18 -0400 Original-Received: by mail-yw0-x22c.google.com with SMTP id x27-v6so6269639ywj.1 for ; Mon, 07 May 2018 10:47:17 -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=gwqY5a4gby2Ksw1acO7TJ4bJvyky8IuZa6aLTbmp+K8=; b=TEYdXUz9DwP4iJKusVa8rC4hh7k1MQtWye1o4Yn8bExTcy1ASNAfKO1N4XQzw5yT2M 7BnyJgfzMzcAC8Xuw6ddzNrU36sgRIZLI6UmE6Wj07MCuMw2IdFUcHaTfwnF4k7lfgc9 XWDA67+rmDKcSylHMLexrtzUYMN7+rjcQfk6n46UPhUQdakGpUNitaWEGxIbE5EANNQz 7xRjRhMBoyr1JlPJfj5Y4ZcqPJsrU7YquZ3HJ3oaNKL6sSZX9jCH4v6Ik2T2NLUTdz9n r2jqxxVTIggxacmtAV0CDLWnSNl4fIs8URRZfXkQVvVnKGv8i4R4yoJMjd4BnZM9L7rY As5g== 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=gwqY5a4gby2Ksw1acO7TJ4bJvyky8IuZa6aLTbmp+K8=; b=RAhqOaFQNmdzJOXuAqSL1KKhy5KkjyuAOhNx4BwQDKPbpfEctqhgzFbH/I3MRwQWsp H9f/mkPzJJcmrPLE9+xwepGXNyYRvKl7QK727jZ38gMjfLplcma6VTEXZay/xd1fHIgW W0D9luAGexBvSFJFWMGOFKltxzGhrA9XSMQWtW5PmF93Szn1LNqt9Vqsq6C2u+Qd3tcp uRhRayQltv6JoHN9LSPxA8oB5n/77KNJF5anps5fnAw+ZR9B46HhDDeLrY0VaBeTuctu L+yrEMWuUrroIsr9kPPJto4vpwphBX7GdFm14wGvIS55/nkBZGVnhly9sIiT2WvRTnp0 k1UQ== X-Gm-Message-State: ALQs6tD/89soTU1a+bAQoge8p7Gbu17iXgOXAjZ8JsvvInoNgtyryyFh B9FZ4UquCDBD5tcFkjYEuTB6bGj4xCbA7WgUVlN+Yg== X-Google-Smtp-Source: AB8JxZpT97MAC+X9T6Wj4IPx+Fjpb8x2lHu6jL/u/eeDWsbj3qSArOiHT1+zcGSlT+u3aIy1qwAHQ5dJt6xti/5aGHU= X-Received: by 2002:a81:8413:: with SMTP id u19-v6mr21520178ywf.487.1525715236861; Mon, 07 May 2018 10:47:16 -0700 (PDT) Original-Received: by 2002:a5b:b08:0:0:0:0:0 with HTTP; Mon, 7 May 2018 10:47:15 -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::22c 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:225128 Archived-At: --000000000000b8bc19056ba142aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 7, 2018 at 7:01 PM, Stefan Monnier 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-em= acs.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, whi= ch > >> is also the implicit point of view of the GNU Coding Standard which us= es > >> "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 ha= s > 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 visite= d > > 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-buffe= r, > > 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=C5=82aw Rzesz=C3=B3tko --000000000000b8bc19056ba142aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 7, 2018 at 7:01 PM, Stefan Monnier <monnier@iro.umo= ntreal.ca> wrote:
>> Similarly
>>
>>=C2=A0 =C2=A0 =C2=A0M-x rename-file RET
>>
>> could try and detect if the source name matches some of the buffer= s's
>> filenames and ask whether we want to rename those buffers's fi= lenames
>> accordingly.
[...]
> People might not remember the whole command nam= e, 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 n= ame which should
just work with your M-x and C-h f examples, so I don't see how those ex= amples
argues in favor of "my commands proposal" instead of using "= rename-file".

I have a file open i= n a buffer in front of me. I want to rename this file and have the buffer b= e changed accordingly: it should now be visiting the file under the new nam= e.=C2=A0

rename-file will instead:
- ren= ame the file but do nothing with the buffer, if I now save the buffer it wi= ll get saved under the old file name. The buffer still visits the file unde= r the old name.
- it will also first prompt for a file to rena= me, while I want to rename the file I am currently editing in a buffer, alo= ng with the buffer.

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


But rename-file-and-buffer ac= ting on the current buffers file is inconsistent with rename-file first pro= mpting for a file to rename, hence the logical way would be to have a new s= et of functions with some shared suffix.
=C2=A0

>> C-x C-w gives you "/current/dir/" is initial input.=C2= =A0 If you then type
>> "/other/dir/" it will "move" the file without = "renaming" it (I
>> personally don't like to make this distinction, probably becau= se
>> I consider the file's name to include all the leading director= ies, which
>> is also the implicit point of view of the GNU Coding Standard whic= h uses
>> "file name" rather than "path" and reserves th= e 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 &q= uot;new
name" and "new directory" into a single UI (tho indeed curre= ntly
C-x C-w doesn't actually "move/rename" but it copies instead)= .

OK, I am completely fine with a singl= e combined move/rename, no disagreement here.
=C2=A0

> include things like deal with version control. A single "move&quo= t; function is
> fine, maybe even the set-visited-file-name semantics are OK, it just h= as 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<= br> `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 an= d 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 matche= s,

Right, and you'll find `rename-file`, which is what I think shou= ld 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 co= mmand
> to move files, except for "file-name", but this matches a to= n of things. I
> am sure many people using Emacs don't even know the concept of a v= isited
> file.

Agreed.=C2=A0 So I find it odd that you insist on having "visit= ed-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 t= o those existing file functions, and to functions that act on buffers, I wa= s thinking of having a third parallel set of functions that acts on the cur= rent 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 s= hould be something like -current-buffer-and-file instead. Maybe it should a= ctually 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 eviden= ced 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= =C2=A0as well.
=C2=A0

> 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 e= xecutes a rename like the one I would like to be able to do, so file+buffer= .
=C2=A0

> There is also an interactive delete-file, obviously there is kill-buff= er,
> 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 sa= me
time, so I'm not convinced there's a need for a separate command fo= r
that.=C2=A0 But as noted, I'd be OK for delete-file to kill the matchin= g
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.=C2=A0 ]=C2=A0

delete-file and rena= me-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 Em= acs 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 li= ke something that specifically acts on the current buffer and its visited f= ile.

Cheers,
Jaros=C5=82aw Rzesz=C3=B3tk= o
--000000000000b8bc19056ba142aa--