GNU bug report logs -
#20739
25.0.50; Dired switches have no effect when explicit list of files provided
Previous Next
Full log
Message #34 received at 20739 <at> debbugs.gnu.org (full text, mbox):
> > > 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.
This bug report was last modified 10 years and 6 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.