From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Rudi C Newsgroups: gmane.emacs.devel Subject: Re: PR: dired-do-create-files now checks for trailing slashes in the target Date: Tue, 28 Sep 2021 23:53:53 +0330 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000be240705cd13fe3e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29498"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Kangas , Eli Zaretskii , tsdh@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 28 22:25:13 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mVJf7-0007Pl-6f for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Sep 2021 22:25:13 +0200 Original-Received: from localhost ([::1]:46358 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVJf5-0000RM-3f for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Sep 2021 16:25:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57484) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVJe5-0008BS-8Y for emacs-devel@gnu.org; Tue, 28 Sep 2021 16:24:09 -0400 Original-Received: from mail-il1-x133.google.com ([2607:f8b0:4864:20::133]:42622) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mVJe3-0008Qv-C5; Tue, 28 Sep 2021 16:24:08 -0400 Original-Received: by mail-il1-x133.google.com with SMTP id a11so319452ilk.9; Tue, 28 Sep 2021 13:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KH9aDHzvrKd7nJ7LRQMeEmErYf4KbtxNxrk8kApkcoE=; b=LahVP6MvM9LvgSH7jYofZAFpt79jtLPu4TIOynn9uwu58Ln7X+gRdgPv2N2NYR2qFd krqIXsej4yyZ4GxToBHQPWteBqhT8SkF3u1Xx91KaaMwJwL/21RSF4CIgeGJokAknGNo 7h/2eEG73DwJtfAp3kPKGWcSmjl80vUjgHYbCj8C5yE2PIvtVy4RutPmrdKfFFD/Nd7O PZWHAiOH1Som3m5t8YATMW1h3jJJyHhcLbp68JlRXJmX5J7jkUOns/h7KALnXaAsH2Bn fY2ZdoLwIvIVw9IQjKYYbvZ5d6FeN0WyUpcziF6eiOpQZ9FsSQ0kPs7nBFzkQjOlVf9d taPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KH9aDHzvrKd7nJ7LRQMeEmErYf4KbtxNxrk8kApkcoE=; b=Sp0cQQhbZPa1aVo7RZlSPf67YWtvzC7GBJcLYIte4lw3P7j5o+OSWXobKxBeaBG5xs fSjhJaT13NLOPgjb0G/UHsW3ZJNhowMy6enMNFwTiONjrvV2ieRcrdXwWIdQAFULugTi u8Dpmuq6l/cShioiQdsoI6Hh8BHyQLcn8ME2IOnAL5lzyHnA0A2uZAEUcOso6q6TcEo8 0ZiIy6lPGQ94a3EeEutA7P/iGRGcA9ngUow1y2yYvV7O667eZT9mE4YSuUbaVLHvDvV2 2nTXuKIOASL+G/+ubIxl7XjU/BEyZTkieU8pW03r7ImdOTmdlk+bllPrXnhbNoW5vpUg t4mw== X-Gm-Message-State: AOAM532LWVxAtmSS3QSBosP7FnO4FAIjJmKPWJs2UA0J/4gHgWpfbO3n qxbg5p5n//fuJkaCnmsAOWKmjQk/NQLhvdWO/+GE+133hMzgIg== X-Google-Smtp-Source: ABdhPJyq7PCxm6s2Udmh44loJ3mDwqk8hbiDFqN5psPn4RdoEs+81Oevf6GCUxb2LzqHVxoT3Ua70GGhuwy9Tkm2BQg= X-Received: by 2002:a05:6e02:1beb:: with SMTP id y11mr5787796ilv.134.1632860645490; Tue, 28 Sep 2021 13:24:05 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::133; envelope-from=rudiwillalwaysloveyou@gmail.com; helo=mail-il1-x133.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:275743 Archived-At: --000000000000be240705cd13fe3e Content-Type: multipart/alternative; boundary="000000000000be240605cd13fe3c" --000000000000be240605cd13fe3c Content-Type: text/plain; charset="UTF-8" > we have functions for distinguishing between a file's name as directory and the directory's file name. Ah, you're right. I have attached a new patch that uses `directory-name-p`. > Does this have some precedent elsewhere? The most famous example is rsync, I guess. Doom's `doom/move-this-file' also does this. (Well, I contributed the directory creation patch to `doom/move-this-file', so make of that what you will.) Also note that `dired-create-destination-dirs' is by default `nil', which means this patch is irrelevant if someone uses the default settings. `dired-create-destination-dirs' being `'ask' will also ask you to confirm creating a new directory. If only you put it to `'always' will it do this "surprising" thing. You also won't lose any data by this surprise, unlike the current behavior that loses the old name of the directory. I am copying tsdh@gnu.org's response here, as I think it might not have gotten to the mailing list. > a reproducible recipe that demonstrates the problem. It solves the problem of moving/copying a file or directory into a not-yet-existing directory. So with the above example, you can do R /new_name/ RET So the behavior will now differ depending on whether new_name already exists or not? because if the user types R /new_ TAB Emacs will complete it to "/new_name/", including the trailing slash. On Tue, Sep 28, 2021 at 10:33 PM Stefan Kangas wrote: > Rudi C writes: > > >> Isn't that backwards-incompatible? > > > > This is an interactive function, I think, so backward compatibility is a > > loose concept here. I can add a configuration variable if you think this > > matters. > > I don't have an opinion on that yet. > > >> similar features in other completion frameworks > > I don't know if `ivy` has this, but anyway, I try to keep this kind of > > hotkeys to a minimum; They are easy to forget, they are not ergonomic, > and > > I have only five fingers from birth, which doesn't help. Why would I > want a > > hotkey when I can perfectly achieve what I need without one, and without > > losing any functionality? > > It feels surprising that if I rename something to "/foo/" my file > suddenly gets moved into a new directory "foo", though. Maybe it's just > me. Does this have some precedent elsewhere? Is this something users > would expect? > --000000000000be240605cd13fe3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> we have functions f= or distinguishing between a file's name as directory and the directory&= #39;s file name.

Ah, you're right. I have attached a new = patch that uses `directory-name-p`.

> Does this= have some precedent elsewhere?=C2=A0

The most fam= ous example is rsync, I guess. Doom's `doom/move-this-file' also do= es this. (Well, I contributed the directory creation patch to `doom/move-th= is-file', so make of that what you will.)

Also= note that `dired-create-destination-dirs' is by default `nil', whi= ch means this patch is irrelevant if someone uses the default settings. `di= red-create-destination-dirs' being `'ask' will also ask you to = confirm creating a new directory. If only you put it to `'always' w= ill it do this "surprising" thing. You also won't lose any da= ta by this surprise, unlike the current behavior that loses the old name of= the directory.

I am copying=C2=A0tsdh@gnu.org's response here, as I think it might n= ot have gotten to the mailing list.

=C2=A0 > a = reproducible recipe that demonstrates the problem.=C2=A0=C2=A0
=C2=A0It solves the problem of moving/copying a file or directory into a<= br>=C2=A0not-yet-existing directory.=C2=A0 So with the above example, you c= an do
=C2=A0
=C2=A0 =C2=A0R /new_name/ RET
So the behavior will no= w differ depending on whether new_name already
exists or not? =C2=A0beca= use if the user types
=C2=A0 R /new_ TAB
Emacs will complete it to &q= uot;/new_name/", including the trailing slash.

On Tue, S= ep 28, 2021 at 10:33 PM Stefan Kangas <stefankangas@gmail.com> wrote:
Rudi C <rudiwillalwaysloveyou@gmail.com&g= t; writes:

>> Isn't that backwards-incompatible?
>
> This is an interactive function, I think, so backward compatibility is= a
> loose concept here. I can add a configuration variable if you think th= is
> matters.

I don't have an opinion on that yet.

>> similar features in other completion frameworks
> I don't know if `ivy` has this, but anyway, I try to keep this kin= d of
> hotkeys to a minimum; They are easy to forget, they are not ergonomic,= and
> I have only five fingers from birth, which doesn't help. Why would= I want a
> hotkey when I can perfectly achieve what I need without one, and witho= ut
> losing any functionality?

It feels surprising that if I rename something to "/foo/" my file=
suddenly gets moved into a new directory "foo", though.=C2=A0 May= be it's just
me.=C2=A0 Does this have some precedent elsewhere?=C2=A0 Is this something = users
would expect?
--000000000000be240605cd13fe3c-- --000000000000be240705cd13fe3e Content-Type: application/octet-stream; name="0001-dired-do-create-files-now-checks-for-trailing-slashe.patch" Content-Disposition: attachment; filename="0001-dired-do-create-files-now-checks-for-trailing-slashe.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ku4im30i0 RnJvbSA5NTFlMTJmMzUyYjc4M2IxNWVkYmFiYjQ2MjNhNWM3MjE0MjViZDI1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWdodE1hY2hpbmFyeSA8cnVkaXdpbGxhbHdheXNsb3ZleW91 QGdtYWlsLmNvbT4KRGF0ZTogVHVlLCAyOCBTZXAgMjAyMSAyMToxNDowNSArMDMzMApTdWJqZWN0 OiBbUEFUQ0hdIGRpcmVkLWRvLWNyZWF0ZS1maWxlcyBub3cgY2hlY2tzIGZvciB0cmFpbGluZyBz bGFzaGVzIGluIHRoZQogdGFyZ2V0CgotLS0KIGxpc3AvZGlyZWQtYXV4LmVsIHwgNCArKystCiAx IGZpbGUgY2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZmIC0tZ2l0 IGEvbGlzcC9kaXJlZC1hdXguZWwgYi9saXNwL2RpcmVkLWF1eC5lbAppbmRleCAzOTdjNWM2N2Ni Li5mY2FhOGRkMDA4IDEwMDY0NAotLS0gYS9saXNwL2RpcmVkLWF1eC5lbAorKysgYi9saXNwL2Rp cmVkLWF1eC5lbApAQCAtMjE1Nyw3ICsyMTU3LDkgQEAgT3B0aW9uYWwgYXJnIEhPVy1UTyBkZXRl cm1pbmVzIGhvdyB0byB0cmVhdCB0aGUgdGFyZ2V0LgogCQkgICAgIHRhcmdldC1kaXIgb3Atc3lt Ym9sIGFyZyByZm4tbGlzdCBkZWZhdWx0KSkpKQogCSAoaW50by1kaXIKICAgICAgICAgICAocHJv Z24KLSAgICAgICAgICAgICh1bmxlc3MgZGlyZWQtb25lLWZpbGUgKGRpcmVkLW1heWJlLWNyZWF0 ZS1kaXJzIHRhcmdldCkpCisgICAgICAgICAgICAod2hlbiAob3IgKG5vdCBkaXJlZC1vbmUtZmls ZSkKKyAgICAgICAgICAgICAgICAgICAgICAoZGlyZWN0b3J5LW5hbWUtcCB0YXJnZXQpKQorICAg ICAgICAgICAgICAoZGlyZWQtbWF5YmUtY3JlYXRlLWRpcnMgdGFyZ2V0KSkKICAgICAgICAgICAg IChjb25kICgobnVsbCBob3ctdG8pCiAJCSAgIDs7IEFsbG93IHVzZXJzIHRvIGNoYW5nZSB0aGUg bGV0dGVyIGNhc2Ugb2YKIAkJICAgOzsgYSBkaXJlY3Rvcnkgb24gYSBjYXNlLWluc2Vuc2l0aXZl Ci0tIAoyLjMyLjAKCg== --000000000000be240705cd13fe3e--