Re: PR: dired-do-create-files now checks for trailing slashes in the target

[Rudi C <rudiwillalwaysloveyou@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2387 bytes --]

> 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 <stefankangas@gmail.com>
wrote:

> Rudi C <rudiwillalwaysloveyou@gmail.com> 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?
>

[-- Attachment #1.2: Type: text/html, Size: 3322 bytes --]

[-- Attachment #2: 0001-dired-do-create-files-now-checks-for-trailing-slashe.patch --]
[-- Type: application/octet-stream, Size: 982 bytes --]

From 951e12f352b783b15edbabb4623a5c721425bd25 Mon Sep 17 00:00:00 2001
From: NightMachinary <rudiwillalwaysloveyou@gmail.com>
Date: Tue, 28 Sep 2021 21:14:05 +0330
Subject: [PATCH] dired-do-create-files now checks for trailing slashes in the
 target

---
 lisp/dired-aux.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 397c5c67cb..fcaa8dd008 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -2157,7 +2157,9 @@ Optional arg HOW-TO determines how to treat the target.
 		     target-dir op-symbol arg rfn-list default))))
 	 (into-dir
           (progn
-            (unless dired-one-file (dired-maybe-create-dirs target))
+            (when (or (not dired-one-file)
+                      (directory-name-p target))
+              (dired-maybe-create-dirs target))
             (cond ((null how-to)
 		   ;; Allow users to change the letter case of
 		   ;; a directory on a case-insensitive
-- 
2.32.0