RE: Sorting of directories in dired

["Drew Adams" <drew.adams@oracle.com>]

    > I've been doing the same thing Juanma does (code above). But
    I wonder if
    > there isn't a bug in `ls-lisp.el'. Notice the commented-out line in
    > `ls-lisp-emulation' (below). Commenting it out does not make
    sense in light
    > of the code of `ls-ignore-case', `ls-lisp-dirs-first', and
    > `ls-lisp-verbosity', together with the fact that `ls-lisp.el'
    is preloaded.

    It does make sense: we don't want those options to have non-nil
    values, we want ls-lisp to produce the same results as with a real
    `ls' program.

    One problem with making the Windows-like behavior the default is that
    if one has a ported ls.exe and uses it to produce Dired buffers, the
    order will be different.  Such inconsistency is bad.

I probably didn't make myself clear. My point was that those other user
options are defined using defcustom in such a way that their values depend
on the current value of `ls-lisp-emulation' - current when the library is
loaded.

As the library is preloaded, there is no way for a user to change the values
of the others by simply changing the value of `ls-lisp-emulation'. The
defcustoms test a value that is, effectively, hard-wired - they might as
well have their values (for Windows) hard-wired as well. The seeming
dependencies are useless - unless I'm missing something.

    > The latter options should not bother to test `ls-lisp-emulation'. They
    > appear dependent on `ls-lisp-emulation', but if that is set
    by a user, it
    > will be set _after_ all of these preloaded defcustoms, so the
    user will in
    > any case be obliged to set each of these options, not just
    > `ls-lisp-emulation'.

    Not true: the user could load ls-lisp from .emacs and then customize
    the options, including ls-lisp-emulation.

In my Windows binary, at least, ls-lisp.el is preloaded. That's the problem.
It does no good for a user to load the library again, since the defcustoms
will then have no effect on the values.

Yes, the user can customize any and all of these, of course. But there is no
effective dependence between them, as the code might lead you (that is, me)
to believe.

    > I would like to see the commented line uncommented again, so
    that these
    > variables all do what they were originally desiged to do for Windows.

    If that line is uncommented, preloading will cause ls-lisp to produce
    Windows-like order

Yes, on Windows (only). And it will get rid of columns that make no sense on
Windows. It will produce a (default) listing like this:

  c:/foo:
  total used in directory 6363 available 16669536
  drwxrwxrwx   1        0 2004-01-15  .
  drwxrwxrwx   1        0 1969-12-31  ..
  drwxrwxrwx   1        0 2004-01-15  bin
  drwxrwxrwx   1        0 2004-01-15  TEST
  -rw-rw-rw-   1    59248 07-04 09:12 bar.el
  -rw-rw-rw-   1    28120 07-04 09:12 bar.elc
  -rw-rw-rw-   1    59268 05-25 17:11 bar.el~
  -rw-rw-rw-   1     2104 07-04 12:37 toto.el
  -rw-rw-rw-   1      853 07-04 12:43 toto.elc

Otherwise, the listing shows something like this:

  c:/drews-lisp-20:
  total used in directory 6363 available 16669504
  drwxrwxrwx   1 dradams  root            0 2004-01-15  .
  drwxrwxrwx   1 dradams  root            0 1969-12-31  ..
  drwxrwxrwx   1 dradams  root            0 2004-01-15  TEST
  drwxrwxrwx   1 dradams  root            0 2004-01-15  bin
  -rw-rw-rw-   1 dradams  root        59248 07-04 09:12 bar.el
  -rw-rw-rw-   1 dradams  root        28120 07-04 09:12 bar.elc
  -rw-rw-rw-   1 dradams  root        59268 05-25 17:11 bar.el~
  -rw-rw-rw-   1 dradams  root         2104 07-04 12:37 toto.el
  -rw-rw-rw-   1 dradams  root          853 07-04 12:43 toto.elc

IOW, aside from putting directories first and not being case-sensitive, the
Windows listing also throws out the uid and gid, which don't mean a lot for
Windows. That saves a lot of real-estate and makes the listing clearer.

    something that we decided not to do.

Right. I can live with that decision.

I'm only pointing out that the defcustom code is a bit silly, wrt Windows.
Might as well hard-wire the values for all of these variables (on Windows),
whatever values you decide upon. Might as well, because the seeming
dependence is illusory, because of the preloading.

    > People, such as Edward, who want "consistent" behavior across
    platforms
    > (e.g. showing columns that make no sense outside of Unix),
    could always
    > change the option values, but the default values should make
    sense for each
    > platform.

    That's not the Emacs philosophy, AFAIK.  Consistent behavior across
    platforms is deemed more important than consistency with other
    platform-specific applications.

OK. But then why does the code in question attempt to modify the behavior
for different platforms? You can't have it both ways, can you?

    > On Windows, it makes sense to show directories first, ignore case
    > differences, and get rid of columns that make no sense.

    The order used by Windows tools is IMHO stupid and user-unfriendly: it
    assumes, for some reason, that people do not look up directories and
    files together.

Fine. It's stupid and user-unfriendly. And it's what people are used to.

Anyway, I have no problem with us choosing the default behavior you want
(it's not what I would prefer, but I can live with it). My point regards the
defcustom definitions.