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

[Drew Adams <drew.adams@oracle.com>]

> > There is a lot in Dired that I think should be exposed/documented
> > better/more.  By default we don't even load dired-x.el or
> > dired-aux.el, and they provide lots of stuff useful even for
> > beginners, including lots of menus.
> >
> > I would be in favor of our loading both of these Dired libraries
> > by default.  There is lots in Dired that users can benefit from,
> > but they are typically unaware of it.
> 
> There is a big difference between exposing and documenting more
> features from dired.

We generally don't document stuff in the manual that is not
exposed by default.  Loading dired-x.el and dired-aux.el
along with dired.el would help users, IMO.  (We are not in
1985 anymore, when it might have made sense to reduce the
default footprint of Dired.)

> I immediately agree on better documentation of
> dired features.  But I am not sure it will make new emacs users
> happy when they get overwhelmed by features they do not understand.
> Advanced users, on the other hand, know how to read the manuals and
> then get the customization they want.

There is no overwhelming by dired-x.el or dired-aux.el.
No one requires anyone to use or even be aware of a
particular command or key that is available.

The proof: `* c' has been available to you since Day One,
as part of dired.el, and you admit that you just learned
about it today.  So clearly its presence did not overwhelm
you all these years. ;-)

> > Marking with `C' is still useful, even if you never do anything
> > with those marks.  It provides a clear indication of the copied
> > files.
> 
> That's exactly why these C's are irritating and inconsistent: the
> properly documented marks `*' and `D' serve the purpose of
> indicating that an action _will be_ performed on certain files.

No, they just mark files, in particular ways (different ways).
They indicate that actions _might_ be performed on the files.

> The C's indicate that an action _has been_ performed

And that actions might be performed on the files they mark.
Via `* c'.

There is nothing unique about `C' marks in that context.
Once you know about `* c' you know that any mark can serve to
both (a) mark files in a particular way, distinguishing them
and (b) allow you to act on them (via `* c').  You can, in
effect, temporarily tag sets of files in different ways
(using different marks), and then act on them.

> and they get into the way when you are using the other marks.

No, not in terms of actions that use those marks.  An action
that acts on `*' marks or `D' marks does not act on `C' marks.

(I assume you meant only `*' and `D' by "the other marks",
though there can be any number of other marks.)

> Say, before marking files for some new action I type `g'
> (revert-buffer).  If this gives me an unmodified buffer, there are
> no left-over marks floating around that I have overlooked.  The C's
> are just in the way for how marks are used otherwise.

You could make a reasonable argument that all marks should
be removed by `g', but that is a separate question.  I might
disagree with that argument, but it is a reasonable one.

(FWIW, if you want to remove all marks you can use `C-x C-v',
but that updates the listing, which `g' does not do.)