emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [External] : Re: Dired C idea


From: Richard Stallman
Subject: Re: [External] : Re: Dired C idea
Date: Thu, 05 Aug 2021 10:12:24 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > All I asked was why replace the command bound to
  > `C'.

Because that's the Dired command to copy files.
I think of rsync as a better way of copying them.
So I think that the default way to do the copying.

When you copy individual files in Dired, it tells you which
have been copied.  That's different from rsync but it achieves
the same purpose.

But in recursive copying of a directory, Dired does not
help you avoid repeated copying when you restart.

           Why not add rsync copying and (if it deserves
  > a binding) give it a different key from `C'?

I don't see a need to have a binding for cp.

I did not know about the command copy-directory, but making that
use rsync seems like a good idea.

I recall that rsync has a bug in handling arguments that contain
spaces.  We would need to get that fixed, in order for this change not
to cause problems.

  > Are you also proposing to remove ordinary copying
  > altogether?

I'm not sure what "altogether" means here, since there are
several levels for how far we could go.

I see no need for Dired to have a key to do cp rather than rsync, when
operating on ordinary local disks.

Someone said it might be better not to use rsync when the files are
accessed through Tramp.  I don't know -- I don't use Tramp.
But I agree we should DTRT about that case.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]