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

[Tassilo Horn]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> Lars, note that we are not talking about a specific command like
>> `dired-do-rename'.  The change is to `dired-do-create-files' which is a
>> workhorse for many dired commands that need some target directory or
>> file, e.g., renaming/moving, copying, symlinking, etc.
>
> Right.  Then it's more invasive than I thought...
>
> Re-skimming this thread, the suggestion is that if the destination
> directory ends with a slash, then that directory is created, and the
> contents of the source is copied (etc) over to it?

Right.  And the creation of a target directory is nothing new but
already exists if `dired-create-destination-dirs' is non-nil.  For
example, when you now (without the patch) copy file.txt to bar/foo where
bar/ doesn't exist, you'll be queried if dired should create it if the
variable is 'ask.  If it is 'always, dired just creates it.  Finally
bar/foo is a normal file, i.e., a copy of file.txt.

With Rudi's patch, it's exactly the same when the destination is
foo/bar.  But if you specify foo/bar/ as destination, dired will create
foo/bar/ (maybe after asking as controlled by
`dired-create-destination-dirs') and you get foo/bar/file.txt.

So basically the trailing / is an indicator to tell dired that the
target must be a directory, and then the `dired-create-destination-dirs'
semantics can apply.  Without the /, dired cannot know.

Therefore, the feature seems very natural to me.  I'm fine with guarding
it with a defcustom if you all feel that many users would type a
trailing / out of habit.  But since the change only triggers if the
directory does not exist yet, the only scenario where it can bite you is
when renaming or copying a directory to a new one and you specify the
new one with trailing / (which completion will never do because there's
no completion for non-existing directories).

> Isn't that just about the opposite of the syntax in rsync?

Sorry, I don't have a lot of rsync experience.  And to me, it's not
really important that dired conforms to rsync conventions.  Instead it
should conform to its own documentation we already have right now.

--8<---------------cut here---------------start------------->8---
dired-create-destination-dirs is a variable defined in ‘dired-aux.el’.

Its value is ‘ask’
Original value was nil

Whether Dired should create destination dirs when copying/removing files.
If nil, don’t create them.
If ‘always’, create them without asking.
If ‘ask’, ask for user confirmation.
--8<---------------cut here---------------end--------------->8---

So when I copy/rename something to the non-existent bar/foo/baz/ where
it's absolutely clear that it's a directory, why on earth should dired
not create it?  I would argue that with Rudi's patch the behavior
conforms more to the current docs than the non-patched dired.

Bye,
Tassilo