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

[Eli Zaretskii]

> From: Andreas Schwab <address@hidden>
> Date: Sat, 24 Sep 2016 22:07:35 +0200
> Cc: address@hidden, address@hidden
> 
> No, they make absolutely no sense.  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.

Before commit 736b582 the doc string didn't mention that EXTENSION
could be a list, either.  Like the optional argument, the fact that it
could be a list was only mentioned in the comment, which was later
moved into the doc string.  So by that logic the list feature also
makes no sense, which is of course absurd.

IOW, this argument proves nothing.

Look, if you want to convince me, either get the author(s) of the code
tell that they made a mistake using that 'P' in the interactive spec,
or come up with a _very_ plausible theory how it could happen without
the author really meaning it to happen.  The interactive spec in its
form before my yesterday's changes was there since the day the
function was added to Emacs.  We need a clear understanding how did
the spec end up being in that form when the programmer didn't mean to
allow specification of the marker.  This stuff doesn't get written by
itself, so any explanation should be good and convincing.

If we cannot prove to ourselves it was an accident or a mistake, then
I object to removing this feature, even if we think it's not very
useful, and even if we don't know who uses it or whether anybody used
it in the past.  I don't think we should knowingly remove existing
features without a very good reason.  Emacs is stable, and "stable"
means existing features don't just disappear.

If we want to have a convenient way of unmarking by extension without
introducing a new function, let's do that without removing this
feature of specifying the marker character.  There are quite a few
examples elsewhere in Emacs for how to get creative with prefix
arguments; I'm sure one of them will allow us to support both features
in this case.