bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#21746: 24.5; purpose of dired-keep-marker-copy?


From: Drew Adams
Subject: bug#21746: 24.5; purpose of dired-keep-marker-copy?
Date: Sat, 24 Oct 2015 14:30:34 -0700 (PDT)

> I know that there are various ways to
> get rid of the C's when copying files in dired.  But nobody showed
> why they are useful in the first place in some common usage scenario
> justifying the current default.

I did.  But you apparently don't want to recognize this use as
being useful.  I'll repeat it, just in case you didn't hear it:

To distinguish/identify the files that were copied.  And to do
so in a way that they can be further acted on in Dired.  IOW,
in a Dired-consistent way.  Both parts of this are useful:
(1) easily see which were copied and (2) easily act on them
or on any subset of them.  #2 requires #1, but #1 is useful
on its own.

How else could Dired distinguish the copied files?  That is,
what are the alternatives?  We can imagine a few:

1. Highlight their lines in some way.  Reasonable.  And with
   similar behavior needs: users need a way to remove the
   highlighting.

   And some might find the higlighting annoying.  But they
   could of course customize its face to remove its effect.

2. Use `*' instead of `C'.  Confusion with other, pre-existing
   `*' marks - no distinction.  Likewise, for `D'.

3. List the copied files only in a separate log buffer.

You can probably come up with some additional ways.

None of these give you the ability to do something with just
those files or a subset of them.

For any proposal you might make, you would need to include some
way to (a) get the list of copied files, (b) perhaps selectively
edit it, and then (c) act on the remaining files in that list.  I.e.,
you need some way to let users act on any subset of those files.

> Therefore 

"Therefore"?  Because no one has shown how `C' marking is useful?
See above.

> I think that the default of dired-keep-marker-copy should be
> changed to nil:
> 
> - The C's are irritating and inconsistent:
> 
>   The marks `*' and `D' indicate that an action _will be_ performed
>   on certain files.  The C's indicate that an action _has been_
>   performed.

Again, `*' and `D' do _not at all_ indicate that any action
_will be_ performed on the marked files.  They indicate that
you _can_ act on them.  Nothing more than that.

And `C' indicates the same thing: you can, with one command/key,
change `C' to `*' or `D', putting all of those files in the
same situation as your beloved (even if untrue) "_will be_
performed" situation.

That's the point of `C' marking: to _indicate_ the copied files.

Not marking the copied files gives you NO way to choose them
for subsequent action.  If they are not marked (or equivalent)
then you cannot distinguish them - they do not stand out from
the rest.

> - There is no future action associated with the C's (nor has anybody
>   shown that this would be desirable)

On the contrary.  There are a great many future actions that
you can perform on the files marked with `C' (by changing `C'
to `*' or `D').

But you certainly cannot do anything to that set of files (or
to a subset) if you cannot distinguish it.  Not identifying
the copied files apparently irritates you less, but it does
not help anyone do anything with them.

It is _not_ that it would always be desirable to do something
additional with all of the files marked `C' (see your claim
that no one has shown that that is desirable).  That's part
of the point: no such hard-coded behavior is appropriate.

What is appropriate is to _be able_ to perform _any_ Dired
action on _any_ of those files (and not only on all of them).

Prerequisites for this ability are (1) being able to
distinguish the copied files and (2) being able to choose
which of them, if any, to act on in some other way.

It sounds to me like you should just customize
`dired-keep-marker-copy' to nil for yourself.  I see no good
argument for changing the default value.  Your only reason to
use `nil' is a personal one: you are irritated by the marks.





reply via email to

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