bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

This regression was apparently introduced in Emacs 25.  It is still
present in the 26.1 pretest.

See the attached screenshots, both from `emacs -Q', one from Emacs 24.5,
the other from Emacs 25.3.1.

1. The #...# files are missing.

2. The .* (dot) files are missing.

3. The order of the other files is changed.

I see the same problem for the default switches: -al.

I find nothing in NEWS about such a change.

And I find it hard to believe this would be by design and not an
accidental regression.  On the other hand, it's also hard to imagine
that no one else has reported this.  (But perhaps this is a duplicate?)


In GNU Emacs 25.3.1 (x86_64-w64-mingw32)
 of 2017-09-26 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --without-dbus --without-compress-install 'CFLAGS=-O2
 -static -g3' PKG_CONFIG_PATH=/mingw64/lib/pkgconfig'

[-- Attachment #2: throw-dired-alF-emacs-25-3-1.png --]
[-- Type: image/png, Size: 11257 bytes --]

[-- Attachment #3: throw-dired-alF-emacs-24-5.png --]
[-- Type: image/png, Size: 21534 bytes --]

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Eli Zaretskii]

> Date: Mon, 18 Dec 2017 10:52:45 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> 1. The #...# files are missing.
> 
> 2. The .* (dot) files are missing.

They are not missing here, at least not in some 2 random directories I
tried, so maybe this is something specific to your system.

> 3. The order of the other files is changed.

This might be due to this change (from NEWS.25):

  *** The ls-lisp package uses 'string-collate-lessp' to sort file names.
  The effect is that, on systems that use ls-lisp for Dired, the default
  sort order of the files in Dired is now different from what it was in
  previous versions of Emacs.  In particular, the file names are sorted
  disregarding punctuation, accents, and diacritics, and letter case is
  ignored.  For example, files whose name begin with a period will no
  longer appear near the beginning of the directory listing.  If you
  want the old, locale-independent sorting, customize the new option
  'ls-lisp-use-string-collate' to the nil value.

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Drew Adams]

> > 1. The #...# files are missing.
> >
> > 2. The .* (dot) files are missing.
> 
> They are not missing here, at least not in some 2 random directories I
> tried, so maybe this is something specific to your system.

You're right.  Those files are mixed in with the others, instead
of being clumped together at the beginning.  My directory listing
is large, and I didn't notice these few files as they were lost
in the sea of "normal" files.

So I guess you can close this bug.

> > 3. The order of the other files is changed.
> 
> This might be due to this change (from NEWS.25):
> 
>   *** The ls-lisp package uses 'string-collate-lessp' to sort file names.
>   The effect is that, on systems that use ls-lisp for Dired, the default
>   sort order of the files in Dired is now different from what it was in
>   previous versions of Emacs.  In particular, the file names are sorted
>   disregarding punctuation, accents, and diacritics, and letter case is
>   ignored.  For example, files whose name begin with a period will no
>   longer appear near the beginning of the directory listing.  If you
>   want the old, locale-independent sorting, customize the new option
>   'ls-lisp-use-string-collate' to the nil value.

Thanks.  Yes, changing the option value to nil solves
everything.

Why the longstanding default behavior changed?  I can see
someone wanting a different order, and so I understand
that we added an option for this.  But why was the default
changed?

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Eli Zaretskii]

> Date: Mon, 18 Dec 2017 12:44:20 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 29766@debbugs.gnu.org
> 
> > > 1. The #...# files are missing.
> > >
> > > 2. The .* (dot) files are missing.
> > 
> > They are not missing here, at least not in some 2 random directories I
> > tried, so maybe this is something specific to your system.
> 
> You're right.  Those files are mixed in with the others, instead
> of being clumped together at the beginning.  My directory listing
> is large, and I didn't notice these few files as they were lost
> in the sea of "normal" files.
> 
> So I guess you can close this bug.

Done.

> >   *** The ls-lisp package uses 'string-collate-lessp' to sort file names.
> >   The effect is that, on systems that use ls-lisp for Dired, the default
> >   sort order of the files in Dired is now different from what it was in
> >   previous versions of Emacs.  In particular, the file names are sorted
> >   disregarding punctuation, accents, and diacritics, and letter case is
> >   ignored.  For example, files whose name begin with a period will no
> >   longer appear near the beginning of the directory listing.  If you
> >   want the old, locale-independent sorting, customize the new option
> >   'ls-lisp-use-string-collate' to the nil value.
> 
> Thanks.  Yes, changing the option value to nil solves
> everything.
> 
> Why the longstanding default behavior changed?

Because it makes Dired on Windows sort in the order that's much more
similar to what it does on GNU/Linux (where 'ls' produces such an
ordering by default in popular locales).

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Drew Adams]

> > Why the longstanding default behavior changed?
> 
> Because it makes Dired on Windows sort in the order that's much more
> similar to what it does on GNU/Linux (where 'ls' produces such an
> ordering by default in popular locales).

And that's a good idea because ___?

I suppose it's good for people using multiple platforms
(consistency).  But since different platforms have
(apparently) such different outside-Emacs behaviors,
perhaps an alist of values, keyed by platform in some
way, would be better.  Then the defaults for common
platforms could be preconfigured according to what
users of those platforms might expect.  And a user
of multiple platforms could opt for either the same
behavior everywhere or different behaviors here and
there.  Just something to think about, I guess.

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Eli Zaretskii]

> Date: Mon, 18 Dec 2017 21:11:00 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 29766-done@debbugs.gnu.org
> 
> > > Why the longstanding default behavior changed?
> > 
> > Because it makes Dired on Windows sort in the order that's much more
> > similar to what it does on GNU/Linux (where 'ls' produces such an
> > ordering by default in popular locales).
> 
> And that's a good idea because ___?

For the same reason Emacs displays files in Dired buffers as "ls -l"
on Unix would, the same reason why we don't put directories first and
display the execute "attribute bit" for programs, which doesn't exist
on Windows, the same reason why we display "inode numbers" if you add
"-i" to the switches.  We do all that, and more, to try to present a
similar UX on all supported platforms.  I thought this was clear to
any veteran user of Emacs.

> I suppose it's good for people using multiple platforms
> (consistency).  But since different platforms have
> (apparently) such different outside-Emacs behaviors,
> perhaps an alist of values, keyed by platform in some
> way, would be better.  Then the defaults for common
> platforms could be preconfigured according to what
> users of those platforms might expect.  And a user
> of multiple platforms could opt for either the same
> behavior everywhere or different behaviors here and
> there.  Just something to think about, I guess.

We already have plenty of such customization options in ls-lisp.el,
had them for a long time.

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Drew Adams]

> > I suppose it's good for people using multiple platforms
> > (consistency).  But since different platforms have
> > (apparently) such different outside-Emacs behaviors,
> > perhaps an alist of values, keyed by platform in some
> > way, would be better.  Then the defaults for common
> > platforms could be preconfigured according to what
> > users of those platforms might expect.  And a user
> > of multiple platforms could opt for either the same
> > behavior everywhere or different behaviors here and
> > there.  Just something to think about, I guess.
> 
> We already have plenty of such customization options
> in ls-lisp.el, had them for a long time.

What option(s) in ls-lisp.el correspond to such an alist?
I don't see any.  And if there is already such an option,
let alone plenty of them, then why did we add
`ls-lisp-use-string-collate'?

Sure, there are plenty of options in ls-lisp.el.  But
which of them are relevant here?

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Eli Zaretskii]

> Date: Tue, 19 Dec 2017 09:08:53 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 29766@debbugs.gnu.org
> 
> > We already have plenty of such customization options
> > in ls-lisp.el, had them for a long time.
> 
> What option(s) in ls-lisp.el correspond to such an alist?

What alist and for which purpose?  You never explained that.

ls-lisp has the following options to adapt it to various styles:

  ls-lisp-emulation
  ls-lisp-ignore-case
  ls-lisp-use-string-collate
  ls-lisp-UCA-like-collation
  ls-lisp-dirs-first
  ls-lisp-verbosity
  ls-lisp-support-shell-wildcards
  ls-lisp-format-time-list
  ls-lisp-use-localized-time-format

> I don't see any.  And if there is already such an option,
> let alone plenty of them, then why did we add
> `ls-lisp-use-string-collate'?

I don't see how an alist could replace ls-lisp-use-string-collate.

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Drew Adams]

> > > We already have plenty of such customization options
> > > in ls-lisp.el, had them for a long time.
> >
> > What option(s) in ls-lisp.el correspond to such an alist?
> 
> What alist and for which purpose?  You never explained that.

As I said:

  But since different platforms have
  (apparently) such different outside-Emacs behaviors,
  perhaps an alist of values, keyed by platform in some
  way, would be better.  Then the defaults for common
  platforms could be preconfigured according to what
  users of those platforms might expect.  And a user
  of multiple platforms could opt for either the same
  behavior everywhere or different behaviors here and
  there.  Just something to think about, I guess.

If you see no way to have alist keys that can be
used to specify per-platform behavior, then that
suggestion is perhaps not feasible.

But otherwise, it could be useful.  An alist entry
of, say, (windows-nt . compare-strings) would have
the effect, when (eq system-type 'windows-nt), of
using `compare-strings' to sort files.  An entry
of (windows-nt . string-collate-lessp) would
instead use ` string-collate-lessp' on MS Windows.

The same user could have preferred settings for
multiple platforms.  The default alist value could
be whatever you like.

> > I don't see any.  And if there is already such an option,
> > let alone plenty of them, then why did we add
> > `ls-lisp-use-string-collate'?
> 
> I don't see how an alist could replace
> ls-lisp-use-string-collate.

See above.  Change the value of the option from
Boolean to alist.  Get the sort predicate from
the alist, checking the key against the current
platform (or whatever - perhaps `system-type'
is not the only reasonable test).

bug#29766: 25.3; REGRESSION, Dired on MS Windows, switches -alF

[Eli Zaretskii]

> Date: Tue, 19 Dec 2017 13:11:30 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 29766@debbugs.gnu.org
> 
> > I don't see how an alist could replace
> > ls-lisp-use-string-collate.
> 
> See above.  Change the value of the option from
> Boolean to alist.  Get the sort predicate from
> the alist, checking the key against the current
> platform (or whatever - perhaps `system-type'
> is not the only reasonable test).

Doesn't seem useful to me.