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

[Eli Zaretskii]

> Date: Sun, 7 Jun 2015 12:33:16 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 20739@debbugs.gnu.org
> 
> > > > > 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

I tried on 3 different systems, one of them GNU/Linux -- none of them
exhibits the behavior you describe.

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

A very simple interpretation: anything that needs to rearrange the
files in any way, by examining them together as a collection.

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

They don't do anything, because the list of files to display is
specified by the caller.

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

'dired' on MS-Windows _calls_ functions in ls-lisp.el, but is not
implemented there.  And the behavior you described, which handles the
case of a list as the 1st arg, is not implemented in ls-lisp.el, it is
implemented in subroutines of 'dired' defined on dired.el.

Now, can we please stop splitting hair?