RE: [found the culprit]

[Drew Adams]

> > I just mentioned what it uses, and has used for a
> > long time.  And it's a general scheme, applied to `dired-do-*'
> > commands generally.  The conflict is not a minor one, e.g.,
> > affecting just `Z'.
> 
> FWIW, I don't think it's a good scheme.

And I (who use it) think it's a good scheme. ;-)

> Better would have more mark-management commands that
> you can then combine with any dired command

We already have great mark-management commands,
including the ability to define multiple sets of
files using different marks (not-known-well-enough
key `* c').

> without having to fight with conflicting uses of C-u.

There's no fight with conflicting uses of `C-u'.
I already explained that it fits well with the
existing prefix arg use for `dired-do-*'.  It
only interprets multiple plain `C-u' specially.

Do you really think that someone needs to rely on
being able to use `C-u C-u C-u' to specify the
current file, instead of just `C-u'?  That makes
no sense to me.

> E.g. commands to "push" and "pop" the current set of marked files,

See `* c'.  I'm guessing that that's the kind of
thing you're aiming for.  But it's more general
than just a stack: direct access to anywhere in
the "stack", to change any set of markings to
another, anytime.

> and a command that you can iterate like your C-u which will first mark
> the current file, then the files in the current directory, then ...
> A nice advantage to C-u is that these would give you visual feedback
> about which files are selected.

So you in fact propose a completely different
use of `C-u' from what Emacs has always used
for `dired-do-*'.  Talk about fighting with
conflicting uses of `C-u'!  That retains
nothing of what we have now wrt a prefix arg.

Anyway, if that's what you want for vanilla
Emacs, go for it.

> > 2. How does the above C-u usage "not follow
> >    Emacs's use of C-u"?
> 
> Emacs usually does not use multiple C-u

"Usually does not use" does not mean that using
multiple `C-u' does not follow Emacs's use of
`C-u'.  Not in the sense of some prescribed use,
in any case.

Emacs usually does not distinguish plain `C-u' from
numeric use.  It doesn't usually do so because
usually - for most commands - there is only one
prefix-arg behavior.  (Actually zero, for most.)

It would be silly to suppose that there were some
unwritten "rule" that "Emacs use" is to not use
prefix args, just because most commands don't use
a prefix arg.  Same thing for a command recognizing
different kinds of prefix arg: don't confuse
frequency of use with prescription of whether or
not to use.

> and also tries to avoid
> distinguishing between "just C-u" and "a numeric
> argument".

I see no indication that Emacs avoids that.  Just
because most commands offer only one prefix-arg
behavior, and so there is no need to distinguish,
that doesn't mean that there is an unwritten
convention to avoid such distinction.

And if there were such a convention (preferably
written), I'd oppose it - but that's just me.
I think the existence of the prefix-arg "feature"
is a good thing.  If it didn't exist it would be
good to invent it.  Same thing for the various
different kinds of prefix arg - I'm thankful for
them.  (I sometimes even wish there were more.)

> There are exceptions to both of those "rules",

I don't agree that there any such rules.  There
are just commands that do not (yet) offer more
than one behavior.  Lots of them.  So what?

And I don't think Emacs should have such "rules".
On the contrary, I think there are many commands
that could benefit from adding alternative
behaviors by way of a prefix arg.  As opposed,
for example, to adding lots of additional key
bindings.

Give me one command and key binding for a related
set of operations, some of which I use much less
often, rather than N commands, bound to N keys,
with N doc strings that are similar but subtly
different ... for the same set of behaviors as
that one key with prefix-arg possibilities.

Saves keys, puts less-used behaviors on slightly
more cumbersome bindings (you have to use a prefix
arg for them), groups related behaviors on similar
keys, facilitates discoverability and recall...

> and I'm to blame for some of those
> exceptions, but I think this case is not a good candidate for an
> exception because there are too many "sets of files" that the user
> might like to specify, so we'll be better served by providing this separately
> than trying to cleverly cram some common cases into the narrow C-u.

It's OK to disagree. ;-)  If I thought there were
other, more common sets of files that users typically
want to act on with Dired then I'd no doubt use
those sets instead.

These are the most common sets that I, at least, want
to act on - they are all ways of acting on "all" files.

Such cases are about as important to me as the case of
wanting to act on just the current-line file.  Just like
that special case (yes, yet another special prefix-arg
case that is built into Emacs), it's about being able
to act on files while ignoring (and so not needing to
change and restore) the current markings.

I'll add this, which you might or might not agree might
be relevant: you've said in the past that you don't
even use Dired, or at least that you don't use it much.

(That doesn't in any way invalidate your arguments,
either about acting on files in Dired or about the
prefix arg in general.)