Re: Sorting of directories in dired

Re: Sorting of directories in dired

[LENNART BORGMAN]

From: Edward O'Connor <hober0@gmail.com>

> Here's one vote for leaving the default as it is. I love how Emacs
> is a consistent environment across the various operating systems it
> runs on, and would much prefer it for the default Dired behavior to
> continue to be the same across all supported systems.


Interesting. I can see your point. However do you use w32? Do you not find it disturbing then that the ordering of files are different in Emacs than outside Emacs on w32?

Maybe you never leave Emacs? But for newbies who are used to other apps under w32, would it not be easier for them to adopt to Emacs if the default ordering was the same as for other apps? And those of us (I know now) who can change it, can't we just do that?

Re: Sorting of directories in dired

[Edward O'Connor]

> Interesting. I can see your point. However do you use w32?

Yes, I do (as well as FreeBSD, Mac OS X, and occasionally GNU/Linux).

> Do you not find it disturbing then that the ordering of files are
> different in Emacs than outside Emacs on w32?

Nope, I don't find that disturbing at all.

A related issue that I *did* find disturbing: on recent versions of
Fedora Core, the default Dired ordering interleaved dot-files with
ordinary files, because of some DWIMish behavior of the underlying `ls'
implementation. I added "setenv LC_ALL C" to my .cshrc to work around
this behavior, because the underlying `ls' doesn't expose any other knob
to control this behavior. Bleah.

> Maybe you never leave Emacs?

I spend a fair amount of time outside of Emacs under w32 (and the other
systems above).

> But for newbies who are used to other apps under w32, would it not be
> easier for them to adopt to Emacs if the default ordering was the same
> as for other apps?

I don't know. I'm not a newbie, and I don't presume to know what would
be easier for them.

> And those of us (I know now) who can change it, can't we just do that?

Of course, and that's precisely what I'll do if this default changes.


Ted

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: Sorting of directories in dired

[Johan Bockgård]

Edward O'Connor <hober0@gmail.com> writes:

> A related issue that I *did* find disturbing: on recent versions of
> Fedora Core, the default Dired ordering interleaved dot-files with
> ordinary files, because of some DWIMish behavior of the underlying
> `ls' implementation. I added "setenv LC_ALL C" to my .cshrc to work
> around this behavior, because the underlying `ls' doesn't expose any
> other knob to control this behavior. Bleah.

See http://www.gnu.org/software/coreutils/faq/coreutils-faq.html
questions 22 and 23.

-- 
Johan Bockgård

Re: Sorting of directories in dired

[Alex Schroeder]

LENNART BORGMAN schrieb:
> Interesting. I can see your point. However do you use w32? Do you not find it disturbing then that the ordering of files are different in Emacs than outside Emacs on w32?
> Maybe you never leave Emacs? But for newbies who are used to other apps under w32, would it not be easier for them to adopt to Emacs if the default ordering was the same as for other apps? And those of us (I know now) who can change it, can't we just do that?

I use Emacs on OSX, Windows, and Slackware.  I would like it to be as
similar as possible.  That being said, I understand the need to cater
for newbies, and I would not mind people adding an option or minor mode
(or theme) to give Unix, Windows, OSX, or any other system's defaults --
as long as I can use those defaults on all the systems I use.

If we start using the current OS to determine defaults, I will have to
find all these variables myself is a slow process of getting used to the
new Emacs and customizing it.

If instead of using a single variable such as window-system we used
another variable such as window-system-preference that defaults to
window-system, then I could set one variable to get all the defaults right.

custom-themes will not make this job easier, but added functionality
that nobody needs makes the coding and testing very tricky.  But that's
something I said years ago...  eg. here:
http://article.gmane.org/gmane.emacs.devel/7002

Alex.
-- 
http://www.emacswiki.org/alex/

Re: Sorting of directories in dired

[Eli Zaretskii]

> Date: Thu, 07 Jul 2005 11:55:19 +0200
> From: LENNART BORGMAN <lennart.borgman.073@student.lu.se>
> Cc: emacs-devel@gnu.org
> 
> Do you not find it disturbing then that the ordering of files are different in Emacs than outside Emacs on w32?

And what, may I ask, do you use outside Emacs?  Isn't it "ls -l"? ;-)

Re: Sorting of directories in dired

[Lennart Borgman]

Eli Zaretskii wrote:

>And what, may I ask, do you use outside Emacs?  Isn't it "ls -l"? ;-)
>
>  
>
Uhm..., I have done that a couple of times...

Sadly enough I am working mostly from the cmd shell. I have tried for 
example MSYS sh, but I found that the integration with ms windows is not 
good enough for me. The cmd shell has become better and better. It 
simply takes too long time to try to use some sh now.

That is also what I have found with my previous tries with Emacs. The 
documentation has been bad on the windows side so those of us windows 
only users who survive as Emacs users do that in resistance to the 
resistance we meet. Everything has taken much, much time. Considering 
that that time is taken from us who wants to promote free software it 
seems to me to be a bad strategy not to help users on w32 as much as we 
can. The majority of the computer users are using w32 (as I guess you 
know ...;-)

I thought I should try to change what w32 users are meeting, but I can 
not do that alone ;-)

Whenever I want to write scripts I use perl.

Re: Sorting of directories in dired

[Eli Zaretskii]

> Date: Thu, 07 Jul 2005 21:53:01 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: hober0@gmail.com,  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
> >And what, may I ask, do you use outside Emacs?  Isn't it "ls -l"? ;-)
> >
> >  
> >
> Uhm..., I have done that a couple of times...
> 
> Sadly enough I am working mostly from the cmd shell. I have tried for 
> example MSYS sh, but I found that the integration with ms windows is not 
> good enough for me.

??? What does the shell have to do with using `ls'?  You can invoke
`ls' from _any_ shell running on Windows, including from cmd.exe.

> That is also what I have found with my previous tries with Emacs. The 
> documentation has been bad on the windows side so those of us windows 
> only users who survive as Emacs users do that in resistance to the 
> resistance we meet. Everything has taken much, much time. Considering 
> that that time is taken from us who wants to promote free software it 
> seems to me to be a bad strategy not to help users on w32 as much as we 
> can.

I think you are misreading the principle of consistent cross-platform
behavior as ``resistance'' or ``a strategy not to help'' w32 users.

Re: Sorting of directories in dired

[Lennart Borgman]

Eli Zaretskii wrote:

>??? What does the shell have to do with using `ls'?  You can invoke
>`ls' from _any_ shell running on Windows, including from cmd.exe.
>  
>
I never use ls outside some sh like shell.

>I think you are misreading the principle of consistent cross-platform
>behavior as ``resistance'' or ``a strategy not to help'' w32 users.
>  
>
Yes, sometimes. On the other hand I think that the necessary integration 
with different platforms must not be hampered by the consistent 
cross-platform behaviour. I am much in favor of both these things.

Since Emacs started its route much have changed. The users on different 
platforms now tend to request that applications adhere to what they are 
used to. After that it is fine to add new features and behaviour. So 
integration and cross-platform behaviour need not collide, but 
integration must not be overseen.

On w32 users are used to that applications can be run out of the box and 
that they behave in a well known manner. That is one of the strengths of 
w32. It is both on surface level and on deeper levels.

Re: Sorting of directories in dired

[Eli Zaretskii]

> Date: Thu, 07 Jul 2005 22:44:02 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: hober0@gmail.com,  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
> >??? What does the shell have to do with using `ls'?  You can invoke
> >`ls' from _any_ shell running on Windows, including from cmd.exe.
> >  
> >
> I never use ls outside some sh like shell.

Why not?

> I think that the necessary integration 
> with different platforms must not be hampered by the consistent 
> cross-platform behaviour. I am much in favor of both these things.

They contradict.  One must choose one or the other; we cannot have
both.

> Since Emacs started its route much have changed. The users on different 
> platforms now tend to request that applications adhere to what they are 
> used to.

FWIW, I don't see any significant change in users' attitudes.

Re: Sorting of directories in dired

[Lennart Borgman]

Eli Zaretskii wrote:

>>I never use ls outside some sh like shell.
>>    
>>
>
>Why not?
>  
>
I can see faster on the output from cmd:s dir what is a directory for 
example.

>>I think that the necessary integration 
>>with different platforms must not be hampered by the consistent 
>>cross-platform behaviour. I am much in favor of both these things.
>>    
>>
>
>They contradict.  One must choose one or the other; we cannot have
>both.
>  
>
We must be more concrete to be able to decide that. Sometimes they 
contradict, sometimes not. I believe we should strive for both. cua-mode 
is a good example on this. viper-mode another (I happily use both). 
emacsserver/client (or gnuserv/client) are other examples.

>>Since Emacs started its route much have changed. The users on different 
>>platforms now tend to request that applications adhere to what they are 
>>used to.
>>    
>>
>
>FWIW, I don't see any significant change in users' attitudes.
>  
>
Would not you think that most users on w32 expect C-x to be cut? Would 
you not expect the keyboard addicts (like me) to use the Alt-key to 
acces the menus?

Re: Sorting of directories in dired

[Eli Zaretskii]

> Date: Fri, 08 Jul 2005 00:06:49 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: hober0@gmail.com,  emacs-devel@gnu.org
> 
> >>Since Emacs started its route much have changed. The users on different 
> >>platforms now tend to request that applications adhere to what they are 
> >>used to.
> >
> >FWIW, I don't see any significant change in users' attitudes.
> >  
> Would not you think that most users on w32 expect C-x to be cut? Would 
> you not expect the keyboard addicts (like me) to use the Alt-key to 
> acces the menus?

They always expected that.  This isn't new.

RE: Sorting of directories in dired

[Drew Adams]

    > From: LENNART BORGMAN
    > Do you not find it disturbing then that the ordering of files
    > are different in Emacs than outside Emacs on w32?

    And what, may I ask, do you use outside Emacs?

I can't speak for Lennart, but I would say that Windows users are used to
seeing, in dialog boxes, Windows Explorer, and elsewhere:

 1. First the directories and then the files.
 2. Files in alphabetical order (by default), without regard to case.

[BTW - Another thing Windows users are used to is clicking a column header
to sort on it (alternate clicks of the same column header switch
directions). I've done this myself for *Buffer List*, but it would be
especially useful for Dired - after the release.]

Sorting of directories in dired

[Lennart Borgman]

In dired files are sorted case sensitive. This does not make sense on an 
OS with case insensitive file system. Is there any way to get the 
listing in dired sorted case insensitive?

Re: Sorting of directories in dired

[Juanma Barranquero]

On 7/7/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> In dired files are sorted case sensitive. This does not make sense on an
> OS with case insensitive file system. Is there any way to get the
> listing in dired sorted case insensitive?

If you're on Windows, dired is using the Lisp emulation of `ls', that
is, ls-lisp.el. You can configure it to be case insensitive. My .emacs
has this:

(when (eq system-type 'windows-nt)
  (setq ls-lisp-emulation   'MS-Windows
        ls-lisp-dirs-first  t
        ls-lisp-ignore-case t
        ls-lisp-verbosity   (nconc (and (w32-using-nt) '(links)) '(uid))))

-- 
                    /L/e/k/t/u

Re: Sorting of directories in dired

[Lennart Borgman]

Juanma Barranquero wrote:

>On 7/7/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>  
>
>>In dired files are sorted case sensitive. This does not make sense on an
>>OS with case insensitive file system. Is there any way to get the
>>listing in dired sorted case insensitive?
>>    
>>
>
>If you're on Windows, dired is using the Lisp emulation of `ls', that
>is, ls-lisp.el. You can configure it to be case insensitive. My .emacs
>has this:
>
>(when (eq system-type 'windows-nt)
>  (setq ls-lisp-emulation   'MS-Windows
>        ls-lisp-dirs-first  t
>        ls-lisp-ignore-case t
>        ls-lisp-verbosity   (nconc (and (w32-using-nt) '(links)) '(uid))))
>  
>
Thanks! Should not this be the default on w32?

Re: Sorting of directories in dired

[Juanma Barranquero]

On 7/7/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Thanks! Should not this be the default on w32?

I suppose it would make sense, yes.

-- 
                    /L/e/k/t/u

Re: Sorting of directories in dired

[Edward O'Connor]

>> Thanks! Should not this be the default on w32?
>
> I suppose it would make sense, yes.

Here's one vote for leaving the default as it is. I love how Emacs
is a consistent environment across the various operating systems it
runs on, and would much prefer it for the default Dired behavior to
continue to be the same across all supported systems.


Ted

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: Sorting of directories in dired

[Juanma Barranquero]

On 7/7/05, Edward O'Connor <hober0@gmail.com> wrote:

> I love how Emacs
> is a consistent environment across the various operating systems it
> runs on, and would much prefer it for the default Dired behavior to
> continue to be the same across all supported systems.

That's the eternal tension between making things "right" and making
them "easy". Using the Windows defaults on Windows would be more
helpful to new users; I'd say it makes sense to lean towards the
newbie's side, if any.

That said, I really have no opinion one way or the other. I don't find
the current situation particularly bad.

-- 
                    /L/e/k/t/u

Re: Sorting of directories in dired

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On 7/7/05, Edward O'Connor <hober0@gmail.com> wrote:
>
>> I love how Emacs is a consistent environment across the various
>> operating systems it runs on, and would much prefer it for the
>> default Dired behavior to continue to be the same across all
>> supported systems.
>
> That's the eternal tension between making things "right" and making
> them "easy". Using the Windows defaults on Windows would be more
> helpful to new users; I'd say it makes sense to lean towards the
> newbie's side, if any.

That's one reason why we need custom themes.  That's where
system-convention-friendly settings should be collected, not all
across the board.

This would resolve the tensions then.

That way, a person coming from a Unix background can with one command
let his Windows Emacs behave like he is accustomed to.

Of course, settings that are _necessary_ on a given platform don't
belong into a theme.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Sorting of directories in dired

[Eli Zaretskii]

> From: Edward O'Connor <hober0@gmail.com>
> Date: Thu, 07 Jul 2005 01:28:22 -0700
> 
> >> Thanks! Should not this be the default on w32?
> >
> > I suppose it would make sense, yes.
> 
> Here's one vote for leaving the default as it is.

Here's another.

> I love how Emacs
> is a consistent environment across the various operating systems it
> runs on, and would much prefer it for the default Dired behavior to
> continue to be the same across all supported systems.

Yes.  Presumably, at least some of the Emacs newbies who use it on
Windows started using Emacs because they want to make some sort of
transition to Posix platforms, or need to work on both types of
systems.

ls-lisp worked like it does today for ages (originally, the options
that make it work like native Windows tools did not exist, they are a
relatively recent addition).

Re: Sorting of directories in dired

[Bill Wohler]

Edward O'Connor <hober0@gmail.com> writes:

>>> Thanks! Should not this be the default on w32?
>>
>> I suppose it would make sense, yes.
>
> Here's one vote for leaving the default as it is. I love how Emacs
> is a consistent environment across the various operating systems it
> runs on, and would much prefer it for the default Dired behavior to
> continue to be the same across all supported systems.

I used to think that too, but it's been my experience (as a UI
programmer) that users really want their OS's look and feel. So, I've
switched my viewpoint to prefer platform-specific look and feels
rather than cross-platform look and feels.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

RE: Sorting of directories in dired

[Drew Adams]

    >>In dired files are sorted case sensitive. This does not make
    sense on an
    >>OS with case insensitive file system. Is there any way to get the
    >>listing in dired sorted case insensitive?
    >
    >If you're on Windows, dired is using the Lisp emulation of `ls', that
    >is, ls-lisp.el. You can configure it to be case insensitive. My .emacs
    >has this:
    >
    >(when (eq system-type 'windows-nt)
    >  (setq ls-lisp-emulation   'MS-Windows
    >        ls-lisp-dirs-first  t
    >        ls-lisp-ignore-case t
    >        ls-lisp-verbosity   (nconc (and (w32-using-nt)
    >                                '(links)) '(uid))))

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.

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'. IOW, the dependency code doesn't work.

---

(defcustom ls-lisp-emulation
  (cond ((eq system-type 'macos) 'MacOS)
	;; ((eq system-type 'windows-nt) 'MS-Windows)
	((memq system-type
	       '(hpux dgux usg-unix-v unisoft-unix rtu irix berkeley-unix))
	 'UNIX))			; very similar to GNU
  ;; Anything else defaults to nil, meaning GNU.
  "*Platform to emulate: GNU (default), MacOS, MS-Windows, UNIX.
Corresponding value is one of the atoms: nil, MacOS, MS-Windows, UNIX.
Sets default values for: `ls-lisp-ignore-case', `ls-lisp-dirs-first',
`ls-lisp-verbosity'.  Need not match actual platform.  Changing this
option will have no effect until you restart Emacs."
  :type '(choice (const :tag "GNU" nil)
		 (const MacOS)
		 (const MS-Windows)
		 (const UNIX))
  :group 'ls-lisp)

(defcustom ls-lisp-ignore-case
  ;; Name change for consistency with other option names.
  (or (memq ls-lisp-emulation '(MS-Windows MacOS))
      (and (boundp 'ls-lisp-dired-ignore-case) ls-lisp-dired-ignore-case))
  "*Non-nil causes ls-lisp alphabetic sorting to ignore case."
  :type 'boolean
  :group 'ls-lisp)

(defcustom ls-lisp-dirs-first (eq ls-lisp-emulation 'MS-Windows)
  "*Non-nil causes ls-lisp to sort directories first in any ordering.
\(Or last if it is reversed.)  Follows Microsoft Windows Explorer."
  ;; Functionality suggested by Chris McMahan <cmcmahan@one.net>
  :type 'boolean
  :group 'ls-lisp)

(defcustom ls-lisp-verbosity
  (cond ((eq ls-lisp-emulation 'MacOS) nil)
	((eq ls-lisp-emulation 'MS-Windows)
	 (if (and (fboundp 'w32-using-nt) (w32-using-nt))
	     '(links)))			; distinguish NT/2K from 9x
	((eq ls-lisp-emulation 'UNIX) '(links uid)) ; UNIX ls
	(t '(links uid gid)))		; GNU ls
  "*A list of optional file attributes that ls-lisp should display.
It should contain none or more of the symbols: links, uid, gid.
nil (or an empty list) means display none of them.

Concepts come from UNIX: `links' means count of names associated with
the file\; `uid' means user (owner) identifier\; `gid' means group
identifier.

If emulation is MacOS then default is nil\;
if emulation is MS-Windows then default is `(links)' if platform is
Windows NT/2K, nil otherwise\;
if emulation is UNIX then default is `(links uid)'\;
if emulation is GNU then default is `(links uid gid)'."
  ;; Functionality suggested by Howard Melman <howard@silverstream.com>
  :type '(set (const :tag "Show Link Count" links)
	      (const :tag "Show User" uid)
	      (const :tag "Show Group" gid))
  :group 'ls-lisp)

---

I suspect that what happened was that the code originally made sense (i.e.
was consistent) with the line uncommented (and it would have made Lennart
and me happy), but someone then decided that this should not be the behavior
for Windows. Instead of removing or commenting-out the corresponding (i.e.
dependent) code everywhere, which would have at least been consistent, only
the Windows line in `ls-lisp-emulation' was commented out.

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.

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. This is especially important for novices. On Windows, it makes
sense to show directories first, ignore case differences, and get rid of
columns that make no sense.

Re: Sorting of directories in dired

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 7 Jul 2005 09:43:59 -0700
> Cc: Emacs-Pretest-Bug <emacs-pretest-bug@gnu.org>
> 
> 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.

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

> 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, something that we decided not to do.

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

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

RE: Sorting of directories in dired

[Drew Adams]

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

Re: Sorting of directories in dired

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 7 Jul 2005 13:35:53 -0700
> Cc: emacs-pretest-bug@gnu.org
> 
> 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.

They might not mean a lot now, but that's only because no one bothered
to write the code to use the Windows equivalents of uid and gid.  I
hope someone will, and rather sooner than later.

> I'm only pointing out that the defcustom code is a bit silly, wrt Windows.

It's certainly not silly on non-Windows platforms.  In the past, I
heard reports of people who were used to ls-lisp and loaded it on
Unix.

> Might as well hard-wire the values for all of these variables (on Windows),
> whatever values you decide upon.

That would make ls-lisp not useful on Unix.  So I don't think it's a
good idea.

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

The default behavior is the same.  The rest are options, users are
free to customize them if they wish.

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

Some people are.

RE: Sorting of directories in dired

[Drew Adams]

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

    They might not mean a lot now, but that's only because no one bothered
    to write the code to use the Windows equivalents of uid and gid.  I
    hope someone will, and rather sooner than later.

You might be right, but I don't think uid and gid will be too useful on
Windows. Uid might be useful, especially for Windows servers. It is good
that users can omit or show uid selectively, of course, and it might even be
good to make that change available as a menu option (a la
`dired-sort-menu.el').

Most Windows users will be on one-user (standalone, personal) boxes,
however, so omitting uid & gid should be the default behavior for Emacs on
Windows.

I'm not even sure that gid has an analog on Windows. We can print "everyone"
or "root" in each row for this column (that's what I see currently), but I
don't think that helps. Again, I might be wrong - although I now use Windows
for Emacs, I'm no Windows guru.

Keep in mind that even when a Dired listing omits columns uid and gid for
Windows files and directories, it still shows them when running Emacs on
Windows and accessing files remotely on, say, GNU/Linux. That is, the
listing shows (should show) the columns that make sense for each platform,
regardless of which platform Emacs is running on. (I'm not sure how it does
that, since the ls-lisp code tests `system-type', but it does (?!))

    > I'm only pointing out that the defcustom code is a bit silly,
    wrt Windows.

    It's certainly not silly on non-Windows platforms.  In the past, I
    heard reports of people who were used to ls-lisp and loaded it on
    Unix.

I specifically mentioned that the only problem was for Windows. There is one
line commented out, and it concerns only Windows. What are you arguing
about?

    > Might as well hard-wire the values for all of these variables
    (on Windows),
    > whatever values you decide upon.

    That would make ls-lisp not useful on Unix.  So I don't think it's a
    good idea.

The part of the `cond' that concerns Windows has no effect on Unix. What are
you talking about? No one mentioned anything about changing the code that
affects `ls-lisp' behavior on Unix. This is about making Emacs on Windows
fit Windows users better, it's not about imposing Windows behavior for Emacs
on Unix.

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

    The default behavior is the same.  The rest are options, users are
    free to customize them if they wish.

Did you look at the `ls-lisp' code I sent? The default (defcustom) behavior
is _not_ the same for each of the platforms. The defcustom form specifically
tailors the behavior to the platform -- _now_ (already). It just does a poor
job of tailoring it to Windows; that's all.

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

    Some people are.

Sigh.

Re: Sorting of directories in dired

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 7 Jul 2005 15:53:58 -0700
> Cc: 
> 
> I don't think uid and gid will be too useful on Windows.

IMHO, they will be as useful as they are on Posix platforms; I don't
see any difference.

> Most Windows users will be on one-user (standalone, personal) boxes,

That is no longer true, by and large.  On any modern Windows box,
there will be several users (administrator is one of them) after the
OS is installed.

> I'm not even sure that gid has an analog on Windows.

There is; check out the docs on MSDN.

Re: Sorting of directories in dired

[Richard M. Stallman]

Could those who are interested in Windows please discuss this
among themselves, not here?