unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Roland Winkler <winkler@gnu.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>, 21746@debbugs.gnu.org
Subject: bug#21746: 24.5; purpose of dired-keep-marker-copy?
Date: Sat, 24 Oct 2015 14:30:34 -0700 (PDT)	[thread overview]
Message-ID: <33f6a584-df3d-48e1-9db1-52d6aa11e5b8@default> (raw)
In-Reply-To: <61261.98098.661987.22059@gargle.gargle.HOWL>

> 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.





  parent reply	other threads:[~2015-10-24 21:30 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-23 19:44 bug#21746: 24.5; purpose of dired-keep-marker-copy? Roland Winkler
2015-10-23 20:30 ` Drew Adams
2015-10-23 20:54   ` Roland Winkler
2015-10-23 21:57     ` Drew Adams
2015-10-24  1:20       ` Roland Winkler
2015-10-24  8:04         ` Drew Adams
2015-10-24  8:11           ` Eli Zaretskii
2015-10-24  9:35           ` Andreas Schwab
2015-10-24 16:05             ` Drew Adams
2015-10-24 16:14               ` Drew Adams
2015-10-24 20:51               ` Roland Winkler
2015-10-24 21:09                 ` Andreas Schwab
2015-10-24 21:34                   ` Drew Adams
2015-10-24 22:00                     ` Andreas Schwab
2015-10-24 21:30                 ` Drew Adams [this message]
2015-10-25  0:15                   ` Michael Heerdegen
2015-10-25  4:01                   ` Roland Winkler
2015-10-25  5:12                     ` Drew Adams
2015-10-25 17:40                       ` Richard Stallman
2015-10-25 12:55                     ` Andreas Schwab
2015-10-25 18:40                     ` Eli Zaretskii
2022-04-28 11:50                       ` Lars Ingebrigtsen
2015-10-29  0:14               ` Juri Linkov
2015-10-29  0:37                 ` Michael Heerdegen
2015-10-29  0:53                 ` Drew Adams
2015-10-24  5:26       ` Eli Zaretskii
2015-10-24  6:10   ` Eli Zaretskii
     [not found] <<36360.86247.586145.22058@gargle.gargle.HOWL>
     [not found] ` <<69182d70-1f68-4105-9f24-7bbef43e7ecb@default>
     [not found]   ` <<40607.80402.459249.22058@gargle.gargle.HOWL>
     [not found]     ` <<987d58d9-30d3-4067-a0ae-7a7722a3f2fb@default>
     [not found]       ` <<83k2qcygzk.fsf@gnu.org>
2015-10-24  8:04         ` Drew Adams
2015-10-24  8:13           ` Eli Zaretskii
     [not found]       ` <<56535.83174.772198.22058@gargle.gargle.HOWL>
     [not found]         ` <<be0730e5-48a6-41c9-97dd-9eb676947d89@default>
     [not found]           ` <<837fmcy9ck.fsf@gnu.org>
2015-10-24  8:17             ` Drew Adams
2015-10-24  8:25               ` Eli Zaretskii
     [not found] <<b3efc431-90b5-4012-acbb-664f8b54e63b@default>
     [not found] ` <<83611wy995.fsf@gnu.org>
2015-10-24  8:21   ` Drew Adams
2015-10-24  8:28     ` Eli Zaretskii
     [not found]   ` <<cf6c5e6b-78d8-432a-8639-7c630e89c74c@default>
     [not found]     ` <<8337x0y8j8.fsf@gnu.org>
2015-10-24  8:34       ` Drew Adams
2015-10-24  8:50         ` Eli Zaretskii
     [not found]       ` <<eeff7ef4-08cd-49b6-bfb2-a4680b996a36@default>
     [not found]         ` <<831tcky7it.fsf@gnu.org>
2015-10-24 16:05           ` Drew Adams
     [not found] <<875f037b-3321-42b7-9128-bb4dd2bd1f7f@default>
     [not found] ` <<834mhgy8pv.fsf@gnu.org>
2015-10-24  8:30   ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33f6a584-df3d-48e1-9db1-52d6aa11e5b8@default \
    --to=drew.adams@oracle.com \
    --cc=21746@debbugs.gnu.org \
    --cc=schwab@linux-m68k.org \
    --cc=winkler@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).