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

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

[Drew Adams]

> Isn't this bug#16533?

I don't know, but I don't think so, after reading that bug thread.

FWIW, in my case the same problem holds for Emacs 24.1.  My impression
from the #16533 thread is that that bug was introduced sometime after
24.1 (but that's not clear to me).

The value of `dired-actual-switches' does get changed, in my case.
For example, in the build for which I reported this bug it gets changed
from "-alF" to "-alFt".  And in Emacs 24.1 it gets changed to "-alF -t".

And the mode line indication does change correctly.  But the file order
does not change - the order is still by file name.

Note that the case I reported is where Dired is reporting about an
explicit list of files, i.e., the DIRNAME argument to `dired' is a
cons, e.g., ("the-Dired-buffer-name" FILE1 FILE2...).  The Dired
listing seems to always show the files in the same order as they
appear in this argument, regardless of `dired-actual-switches'.

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

[Drew Adams]

> they are listed in the order in which you specified them in the list
> passed as the first argument to 'dired'.  That just happened to
> coincide with alphabetic order in your case.

Right.  I misspoke.

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

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?

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.  That makes sense, to me anyway.

We should be able to easily make Dired at least report correctly
about the switches behavior that it gets right, and make it tell
users not to expect other switches to have any effect in this
use case.

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

And either the list of those that are useful (not ignored) should
be given explicitly (but that can be platform-dependent), or at
least a couple examples that are typically relevant can be given.

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.

Here is one possibility for the mode-line lighter: `Dired/*-hiF'.
Here, I'm using:

* "*" to indicate listing selected files instead of a directory.

* "-hiF" are the relevant `ls' switches.  (Irrelevant switches
  given by the user are ignored - this indicates which are used.)

* "/" instead of "by ".  So `Dired/name' and `Dired/date'.

  FWIW: I do this /-for-by replacement anyway in my code, to save
  space and because I add more info to the lighter than just the
  sort order.  When files are marked or flagged I add that info
  to the lighter.  E.g., `Dired/name 3* 2D', with the `3*' and
  the `2D' highlighted using,by default, the same faces as marks
  `*' and `D'.

  If the current line is marked/flagged, then the lighter shows
  how many are, both through that line and total.  For example,
  `Dired/date 6* 2/9D' says this: There are 6 marked lines
  and 9 flagged lines; the file on the current line is flagged;
  there is one flagged above it and there are 8 flagged below it.

That's just one possibility, for discussion.  `*' is maybe not
the best indicator of an explicit listing; dunno.  And maybe
it won't be easy to always correctly get the list of relevant
switches; dunno.

FYI - The code for the mode-line indicator that I use now (e.g.,
showing number of marks and flags) is in function
`diredp-nb-marked-in-mode-name', in `dired+.el'.  It could be
added to vanilla dired.el, if wanted.  In dired+.el, that function
is added to these hooks:

(add-hook 'dired-after-readin-hook 'diredp-nb-marked-in-mode-name)
;; `find-dired' does not call `dired-readin'.
(add-hook 'dired-mode-hook         'diredp-nb-marked-in-mode-name)

Here is the code for the function.

(defun diredp-nb-marked-in-mode-name ()
  "Add number of marked and flagged lines to mode name in the mode line.
\(Flagged means flagged for deletion.)
If the current line is marked/flagged and there are others
marked/flagged after it then show `N/M', where N is the number
marked/flagged through the current line and M is the total number
marked/flagged.

Also abbreviate `mode-name', using \"Dired/\" instead of \"Dired by\"."
  (let ((mname  (format-mode-line mode-name)))
    ;; Prop `dired+-mode-name' indicates whether `mode-name' was changed.
    (unless (get-text-property 0 'dired+-mode-name mname)
      (save-match-data
        (setq mode-name
              `(,(propertize
                  (if (string-match "^[dD]ired \\(by \\)?\\(.*\\)" mname)
                      (format "Dired/%s" (match-string 2 mname))
                    mname)
                  'dired+-mode-name t)
                 (:eval
                  (let* ((dired-marker-char
                          (if (eq ?D dired-marker-char)
                              ?*
                            dired-marker-char))
                         (marked-regexp (dired-marker-regexp))
                         (nb-marked
                          (count-matches
                           marked-regexp (point-min) (point-max))))
                    (if (not (> nb-marked 0))
                        ""
                      (propertize
                       (format
                        " %s%d%c"
                        (save-excursion
                          (forward-line 0)
                          (if (looking-at (concat marked-regexp ".*"))
                              (format "%d/" (1+ (count-matches
                                                 marked-regexp
                                                 (point-min) (point))))
                            ""))
                        nb-marked dired-marker-char)
                       'face 'diredp-mode-line-marked
                       'dired+-mode-name t))))
                 (:eval
                  (let* ((flagged-regexp
                          (let ((dired-marker-char  dired-del-marker))
                            (dired-marker-regexp)))
                         (nb-flagged
                          (count-matches
                           flagged-regexp (point-min) (point-max))))
                    (if (not (> nb-flagged 0))
                        ""
                      (propertize
                       (format
                        " %s%dD"
                        (save-excursion
                          (forward-line 0)
                          (if (looking-at (concat flagged-regexp ".*"))
                              (format "%d/" (1+ (count-matches
                                                 flagged-regexp
                                                 (point-min) (point))))
                            ""))
                        nb-flagged)
                       'face 'diredp-mode-line-flagged))))))))))

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.

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

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?

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

[Drew Adams]

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

You can try the same build I used, by downloading it from Dani's site:
http://sourceforge.net/projects/emacs-bin/.  That will take about 3
minutes altogether.  Or you can take my word for it.  The example I
gave, and any number like it, are reproducible:

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

(You can use just "-r" as well.)

> > > Why do you think that what is controlled by the ls-lisp.el
> > > code has nothing to do with this bug report?
>
> 'dired' on MS-Windows _calls_ functions in ls-lisp.el, but is not
> implemented there.

No one said the ls-lisp.el implements Dired entirely.  It is,
however, mostly responsible for the Dired listing that is produced.
And that is the question here - what listing gets produced.

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

I don't agree.  When DIRNAME is a cons, `dired-insert-directory' is
called with the buffer name as 1st arg, the switches as 2nd arg,
and the list of files to be listed as the 3rd arg.  That passes each
of the files in the list, in turn, to `insert-directory', which
passes each of them to `ls-lisp-insert-directory'.

It is very much `ls-lisp-insert-directory' which is involved in
the behavior we are discussing.  It is that function that handles
switch -B in the bugged way I reported.  And it is that function
that inserts the file and dir lines in the Dired buffer, correctly
or not.

Furthermore, in the case of a cons DIRNAME, `ls-lisp-insert-directory'
is passed nil as its FULL-DIRECTORY-P arg, even for a directory in
the list.  (When DIRNAME is a directory, `t' is passed as arg
FULL-DIRECTORY-P, and the behavior and code path is quite different.)

In sum, `ls-lisp-insert-directory' handles the listing of the
individual files & dirs contained in the cons DIRNAME arg to `dired'.
 
> Now, can we please stop splitting hair?

Who's splitting hairs, Eli?  You seem to want to say that the
bug is fixed because you have stated in the doc (admittedly I
have not seen the actual text) that switches that involve sort
order have no effect when DIRNAME is a cons.  Or perhaps you
said something less committal, such as that some switches are
not supported.

My point is that the bug is about fixing the *behavior*, not just
copping out in the doc.  Most switches can be made to DTRT when
DIRNAME is a cons.  And switch -B for ls-lisp can at least be
fixed in the way I indicated, to prevent a wrong-type-arg error.

The bug subject line, and my detailed description of the bug,
are about the fact that "Dired switches have no effect" when
DIRNAME is a cons.  It is not that the doc for this use case
is incorrect or insufficient.  It's great to improve the doc
also, but that doesn't fix the problem I reported.  That's all.
That's not splitting hairs, in my book.

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

[Drew Adams]

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

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

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.

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.

BTW, I see a bug for `B':

(dired-other-window '("foo" "toto.el" "foo.el") "-B")

The problem is at the beginning of `ls-lisp-insert-directory, AFAICT.
There we see this code on the first line:

(if (or wildcard-regexp full-directory-p)

But that is incorrect, because when switch `B' is used
we do this (ugly hack) in `ls-lisp--insert-directory':

(if (memq ?B switches) (setq wildcard-regexp "[^~]\\'"))

and this, similarly:

(setq wildcard-regexp (if (memq ?B switches) "[^~]\\'")
      file            (file-relative-name orig-file))

IOW, we use a pseudo wildcard-regexp.

And that doesn't work with this call:
(directory-files-and-attributes
  dir nil wildcard-regexp t (if (memq ?n switches) 'integer 'string))

Debugger entered--Lisp error: (file-error "Opening directory"
 "No such file or directory" "d:/the/path/to/foo.el/foo.el/")
  directory-files-and-attributes("foo.el/" nil "[^~]\\'" t string)
  ls-lisp-insert-directory("foo.el" (66) nil "[^~]\\'" nil)
  ls-lisp--insert-directory(...

If I change the (if (or wildcard-regexp full-directory-p) to this
then it seems to fix the problem of raising an error:

 (if (or (and wildcard-regexp
              (not (string= "[^~]\\'" wildcard-regexp)))
         full-directory-p)

But that is not a complete fix.  It does not solve the
problem that `B' does not work for a cons DIRNAME.  

I'm not sure what the right fix is for that, since it's not
clear to me where switch `-B' is handled.  A guess is that
for a whole directory (not for a cons DIRNAME or for a non-dir
filename) it is handled by `directory-files-and-attributes'.
And I'm guessing that that function should still (after a fix)
be called only for the non-cons DIRNAME case.

In that case, I'm guessing that `ls-lisp-insert-directory'
should test for the pseudo wildcards-regexp "[^~]\\'" and
should then DTRT to list the entry showing the block size.
Maybe you can take a look at what that code should be.

Of course, we can just implement the fix I described above,
to prevent an error being raised, and document that `-B' is
not supported for cons DIRNAME.  It would be better to make
it DTRT, however.  This switch needs only to consider a
single file or dir name entry, so it should be possible to
support it.

[BTW, `g' and `n' are listed as supported, but the ls-lisp doc
says that `l' is always assumed (cannot be overridden), so I
don't think `g' or `n' is really supported (`g' is supposed to
be like `l' but does now show owner; `n' is supposed to show
numeric user and group ids).  At least I don't see `g' and `n'
having any effect.  Perhaps this is an ls-lisp.el bug?]

IOW, the switches that correspond to your "Yes" agreement,
above, have no effect when DIRNAME is a cons.

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

It is not about the `s' toggle.  It is about switches.  There are
multiple switches that are currently not supported for cons DIRNAME,
including but not limited to most of the switches that handle sort
order.

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

[Drew Adams]

Sorry; what I said about switch -B was correct, except about it
showing block sizes.  I should have said that it filters out
backup files.

The rest of what I said about should be OK.  In particular, the
fix I showed, that lets a cons DIRNAME not raise an error with
-B, still does not solve the problem that -B does not work here.
That is, no error is raised, but backup files are not filtered
out. 

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

[Eli Zaretskii]

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

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

[Drew Adams]

> a bug for `B':
...
> Debugger entered--Lisp error: (file-error "Opening directory"
>  "No such file or directory" "d:/the/path/to/foo.el/foo.el/")
>   directory-files-and-attributes("foo.el/" nil "[^~]\\'" t string)
>   ls-lisp-insert-directory("foo.el" (66) nil "[^~]\\'" nil)
>   ls-lisp--insert-directory(...

FYI, I submitted the fix as a patch in a separate bug report, #20776.

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

[Drew Adams]

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

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

[Eli Zaretskii]

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

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

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

I do.

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

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

They are also shown without -A or -a.  Specifying any files lists them
regardless.

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

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

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

[Drew Adams]

emacs -Q

Given two files whose names are a.el and b.el, with b.el more recent
than a.el.

M-: (dired '("foo" "a.el" "b.el") "-lstF")

The files are listed in alphabetic order, not by date as specified by
arg SWITCHES and as indicated in the mode line.

Hitting `s' any number of times has no effect on the order of the
files.  But it updates the mode line in a misleading way, saying
alternately that the files are ordered by dated.



In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2014-10-20 on LEG570
Bzr revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'

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

[Eli Zaretskii]

> Date: Fri, 5 Jun 2015 01:34:40 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> emacs -Q
> 
> Given two files whose names are a.el and b.el, with b.el more recent
> than a.el.
> 
> M-: (dired '("foo" "a.el" "b.el") "-lstF")
> 
> The files are listed in alphabetic order, not by date as specified by
> arg SWITCHES and as indicated in the mode line.
> 
> Hitting `s' any number of times has no effect on the order of the
> files.  But it updates the mode line in a misleading way, saying
> alternately that the files are ordered by dated.

Isn't this bug#16533?

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

[Eli Zaretskii]

> Date: Fri, 5 Jun 2015 01:34:40 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> emacs -Q
> 
> Given two files whose names are a.el and b.el, with b.el more recent
> than a.el.
> 
> M-: (dired '("foo" "a.el" "b.el") "-lstF")
> 
> The files are listed in alphabetic order, not by date as specified by
> arg SWITCHES and as indicated in the mode line.

No, they are listed in the order in which you specified them in the
list passed as the first argument to 'dired'.  That just happened to
coincide with alphabetic order in your case.

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