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

[Drew Adams]

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

(I forgot the quote before the list arg, as I'm sure you realized.)

> Not in my Emacs, built from the latest development sources.

Interesting.  I definitely see the list reversed correctly, even
in this very recent build:

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2015-05-29 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/mingw32 --host=i686-pc-mingw32
 --enable-checking=yes,glyphs'

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

An odd interpretation of sort order.  If the doc relies on users
understanding things that way then I'd suggest that it won't
work as intended. ;-)

> > 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.
> 
> It shows them in column-wise order.

What does that even mean?  The order of the files listed is
unchanged from the input order in DIRNAME.  What is changed
(removed) is the display of fields besides the file/dir name.

> > > 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.
> 
> They are also shown without -A or -a.  Specifying any files lists
> them regardless.

Which is just another way of saying that -A and -a do not remove
those dot names.  We are agreeing about the effect, but not about
what it means.  IMO, it means that these switches do not do what
they say.  In your opinion (I guess) they do what they say, because
a user must understand what they say to mean that they do not
do what they explicitly in this case, i.e., they do not remove .
and ...

> > Why do you think that what is controlled by the ls-lisp.el code
> > has nothing to do with this bug report?
> 
> Because 'dired' the function is not defined in ls-lisp.el, and it
> works even without ls-lisp.

On MS Windows (my report is from a Windows build) it uses ls-lisp
by default, no?  The manual says this:

 Dired normally uses the external program `ls' to produce the directory
 listing displayed in Dired buffers (*note Dired::).  However,
 MS-Windows and MS-DOS systems don't come with such a program, although
 several ports of GNU `ls' are available.  Therefore, Emacs on those
 systems _emulates_ `ls' in Lisp, by using the `ls-lisp.el' package.
 While `ls-lisp.el' provides a reasonably full emulation of `ls', there
 are some options and features peculiar to that emulation; they are
 described in this section.

And even if it does work in some cases without ls-lisp, my bug
report is about fixing Dired generally, including (explicitly)
when ls-lisp is used.  Why look for some cases where it might
work as a way to claim that there is thus no bug if it does
not work in other cases?  Especially cases that I specifically
reported on from the beginning in the 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).
> 
> Exactly.  And they have or don't have effect regardless of ls-lisp.

OK, as long as fixing them includes fixing them for ls-lisp.

And I pointed out the particular case of -B, for which it is not
true (AFAIK) that it has or doesn't have "effect regardless of
ls-lisp."  The specific problem I pointed to wrt -B is ls-lisp
only (AFAIK).