RE: Dired: Improve symmetry in mark/unmark commands bound to keys

[Drew Adams]

> The prefix was obviously never
> intented to be used with this command.  The only intented use of the
> second argument was the its caller, dired-flag-extension.  That is easy
> to prove, because before commit 736b582 it wasn't even documented in the
> doc string.

Yes.  More importantly, we can do what we think is best.

What do we really need?

1. We need for `dired-flag-extension' to work.  With the current
   implementation that means calling `dired-mark-extension' with
   a `D' mark.

2. We need a command for changing the mark character that is used
   for the currently marked files.  We have that: `* c'
   (`dired-change-marks').

3. We need a command to mark files that have a given extension.
   We have that: `* .' (`dired-mark-extension').

4. We need a command to unmark files that have a given extension.
   We do NOT have this.

5. Do we need a command that marks files that have a given
   extension and prompts you for which mark character to use?
   This is currently provided by `* .' with a prefix arg.

I agree with Tino and Andreas that #5 is not needed.  It has never
been used, AFAICT.  #2 suffices for getting whatever marks you want.

I agree with them also that we do not need a new, separate command
for #4, and that we should let `* .' also unmark, with a prefix arg.

Two possibilities, if we want that behavior for `* .':

a. Redefine `dired-mark-extension' to do that.  In this case,
   the implementation of #1 needs to change (provide a helper).

b. Define a new command.  Call it `dired-mark-or-unmark-extension'.

For (b): The other commands for which a prefix arg unmarks
rather than marks do NOT have "-or-unmark" in the name.

Should they, to distinguish them from those that only mark or
only unmark?  For example, should `dired-mark-files-regexp' be
called `dired-mark-or-unmark-files-regexp'?

That brings us back to the question of thread "Ibuffer: w and B
default to buffer at current line".  I think we should name the
commands after only the _default_ behavior, i.e., what happens
if you do not use a prefix arg.  So I'd argue for just making
`dired-mark-extension' unmark with a prefix arg (and providing
a different helper function for `dired-flag-extension') -
unless someone can point out how using a prefix arg to specify
the mark character is actually useful for `* .'.

On the other hand, there are some commands that only mark or
unmark, and for which either (a) the opposite behavior is not
useful or (b) the prefix arg is used for something else, and
two different keys might be provided for marking and unmarking.
For example, `* m' just marks, and `* u' just unmarks.  Such
exceptions also include `* ?' (`dired-unmark-all-files') and
`* !' (`dired-unmark-all-marks').

Other than such exceptions, should commands that currently only
mark or unmark, and for which both operations are useful, also
do double-duty, via a prefix arg?  For example, should `* s'
unmark all with a prefix arg (one of Tino's proposals)?
 
Most commands that unmark also unflag - they remove all marks,
including `D' (deletion flag).  The doc strings make this clear -
except the doc string of `dired-unmark'.  Shouldn't that doc
string also make this clear?

There is maybe a little room for some minor cleanup and making
the command set a bit more consistent.  On the other hand, all
things are not equal, and forcing consistency where it is not
appropriate is not the answer either.  There is no imperative
to paint with a broad brush.  In most cases there are good
reasons for the current command behavior, I think.