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

[Eli Zaretskii]

> Date: Sat, 6 Jun 2015 11:43:20 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 20739@debbugs.gnu.org
> 
> > You evidently expected 'dired' to apply the order-related options in
> > switches to the entire list of files.  But that's not what 'dired'
> > does when it is called with its 1st argument a list.  What it does
> > is invoke 'insert-directory' with each of the files in the list, in
> > order, passing it the value of switches.  So when calling 'dired' in
> > this manner, the order-related switches have no effect whatsoever.
> 
> I think you are describing what it does, and not what it should
> do or perhaps could do, and which would be more in line with user
> expectations.  Yes, that is what the behavior is now.

I'm describing what it does, yes.  I have no idea what it should do;
it's not like there's a requirements document somewhere that we could
consult.  And the documentation leaves that unspecified.

> A priori, a user can reasonably expect switches to have their usual
> effect.  Can we at least keep this expectation/request open as an
> enhancement request?

I didn't close the bug.

> In any case, the problem wrt `ls' switches is not total.  Some parts
> of this bug/enhancement can be taken care of (fixed) more easily.
> 
> `i', for instance, shows inodes, and `h' shows file sizes in
> human-friendly units.  But other switches are not reflected in the
> Dired behavior when you provide an explicit list of files and dirs.
> 
> The behavior is limited, I'm guessing, wrt any parts of `ls' that
> depend on the whole list of files and subdirs.  It seems that parts
> of the `ls' behavior that depend only on the info about a given
> file are retained.

Yes.

> > I've updated the doc string to mention this peculiarity.
> > 
> > > Hitting `s' any number of times has no effect on the order of the
> > > files.
> > 
> > For the same reason.
> 
> 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.

> Second, it's not just about the doc string.  If no improvement
> in the behavior is to be expected (I would prefer that it be
> improved to respect the switches generally, to the extent that is
> possible), then I think a minimum bug fix, beyond the doc (see
> above), would be to change the mode-line lighter.  At a bare
> minimum, the misleading lighter indications "by name|date" need
> to be removed.
> 
> Whe DIRNAME is a cons, the lighter should not show anything like
> "by name" or "by date".  Instead, it should either have just
> "Dired" or (better) include some indication that the listing is
> from an explicit list and not necessarily a directory listing.
> In the latter case, it could also show the (relevant) switches.

The 's' toggle's implementation is problematic to begin with, IMO, so
it's small wonder that it doesn't work right in this case.