bug#20739: 25.0.50; Dired switches have no effect when explicit list of files provided

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 6 Jun 2015 14:57:05 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 20739@debbugs.gnu.org
> 
> > > First, the doc should specify what I said above (if it is in fact
> > > the case): `ls' behavior that depends on the entire list is not
> > > available for this use case - the only switches that affect the
> > > display are those that depend only on the info for an individual
> > > file or dir; other switches are ignored.
> > 
> > I've found no switches that are ignored as result of this
> > implementation, except those that control the order of the files in
> > the listing, so that's what I stated in the doc string.  I think
> > this makes the actual behavior clear enough.
> 
> It is not about the order.  `r' works, for example - it reverses
> the order.

No, it doesn't.  The order is always the same as in the list you pass
to 'dired'.

> And anyway I don't think that sort-order switches are the only
> ones that are ignored/irrelevant when DIRNAME is a cons.

Which other switches are ignored?

> It's not about switches that control the order.  It's about switches
> that deal with directory (or directories) themselves, their entire
> contents, as opposed to switches that deal only with an individual
> entry to be listed or that (like `r') deal only with the set of
> entries without needing any knowledge of the directory.

Yes, and those are all the switches that control the order of
presenting the files in the listing.

> On MS Windows `ls-lisp.el' is used, and it says that it supports
> all of these switches: A a B C c F G g h i n R r S s t U u v X
> 
> I think that besides `t' and the other sort switches (besides `r'),
> at least `A', `a', `B', and `C' have no effect.

"-C" is about the order; the others are meaningless when you specify
the files explicitly.  The doc string already says that the list of
files to display is specified by the 1st argument in this case.

So I think the current doc string, after yesterday's changes, fixes
the issues you raised.

Your other points are specific to ls-lisp.el, so they don't really
belong to this bug report, IMO.