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

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

> > > 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'.

That's not what I see.

(dired ("foo" "/path/to/bbbbb" "/path/to/foo.el" "/path/to/bar.el")
       "-alFr")

shows the files in Dired in the reverse order: bar.el, foo.el,
bbbbb.  Switch -r, even though it is about the sort order, works
fine with a cons DIRNAME.  Here anyway (with emacs -Q).
     
> > 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.

I don't agree.  Unless you are interpreting "switches that control
the order" as including any switch that affects the display.

You say that -C, for instance, "controls the order".  At least
here (I'm using Cygwin), -C lists the entries by columns.  It
does not change/control the order.

And (here anyway), -C has no effect with a cons DIRNAME: With
string DIRNAME, -C lists only the file names.  With cons DIRNAME,
the -C shows a full listing of fields, not just file names.

> > 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.

Whether -A, -a, and -B are meaningless is in the eye of the user.
The point is that if you specify an explicit . or .., switch -A
still lists those directories.  And switch -a still lists dot files
that are in the explicit list.  And switch -B still lists backup
files that are in the list.  Such behavior means that those
switches have no effect when DIRNAME is a cons.  And they have
nothing to do with sort order.  And each could be made to work,
I think: they require no knowledge of the directory; they just
filter the input file names.

> 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.

I don't have that doc string, but I'll take your word for it,
modulo what I've noted above.  A user should not get the
impression that switches such as -A, -a, and -B work, even
though they are not about controlling the sort order.  IMO, it
is not about sort order.

> Your other points are specific to ls-lisp.el,

No, they are not.  The mode-line lighter, for instance, has
nothing to do with ls-lisp.  It is incorrect for the lighter
to indicate the order as being "by name" or "by date" when
it is not.

> so they don't really belong to this bug report, IMO.

Why do you think that what is controlled by the ls-lisp.el code
has nothing to do with this bug report?

The bug is about certain Dired switches having no effect when
DIRNAME is a cons, even though they could work (have the usual
effect).

It is about fixing that no-effect behavior and documenting the
no-effect behavior for the remaining switches that are meaningful
only for a directory.  The switches that need to be fixed are
those that could apply to an explicit set of files and dirs.

The fact that the ls-lisp code for -B does not work, and that
it raises an error, is part of this bug.  I proposed a simple
fix for the erroneous error raising.  Why not apply it?  And
why not eventually fix the problem completely, so that -B is
supported?  There is no reason not to support it, IMO.  If
there is a lack of resources, then let's keep the bug open
until someone steps up.  But the error-raising part of the
problem can be fixed now, trivially.

That's what this bug is about: fixing the fact that some
switches that could be effective with a DIRNAME cons are
currently ineffective.  And fixing the doc so that whatever
the behavior is with a cons DIRNAME, it is clearly described.
It sounds like you have worked on the latter part, which is
great.  Thanks for that.