Sorting of directories in dired

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

theming (was: Sorting of directories in dired)

[John S. Yates, Jr.]

On Thu, 07 Jul 2005 01:28:22 -0700, Edward O'Connor wrote:

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

With all of RMS's push to get the current, little-used theme code
debugged and integrated I keep feeling that it simply will not
address what I intuitively feel a theme concept should provide.
Edward's comment quoted above provides a perfect case in point.

Historically, the Emacs community has provided default behavior
that catered to its entrenched userbase.  The answer to nearly
any suggestion that such behavior might be awkward / unfamiliar /
jarring to new users, especially those on platforms held in low
regard by the entrenched userbase, is that Emacs is customizable.
Essentially a "Let them eat cake" attitude.  The learning curve
and shear volume of customization needed to make Emacs feel
comfortable to a new Windows user (who may very well some day
in the future run Emacs on *nix, but today has no interest in
investing effort in such a potentiality) is daunting.

My notion of a theme is not a named collection of configuration
settings.  Rather it is an expression of high-level intent:

- as much as possible behave like Window / MacOS / *nix
- underline clickable links
- give me single frame behavior vs something like Drew's OneOnOne

This is not unprecedented.  There already seems to be a bit of
this kind of mindset in the attempt to provide light-on-dark and
dark-on-light default faces.

/john

Re: theming

[Lennart Borgman]

John S. Yates, Jr. wrote:

>My notion of a theme is not a named collection of configuration
>settings.  Rather it is an expression of high-level intent:
>
>- as much as possible behave like Window / MacOS / *nix
>- underline clickable links
>  
>
I agree to whole message. I have written EmacsW32 just for this above. 
It would be better if this idea was merged into Emacs. I think however 
that it has to coexist with themes in some way and perhaps themes can be 
the underlying structure for this.

Re: theming

[Juanma Barranquero]

> I agree to whole message. I have written EmacsW32 just for this above.

Much as I like the idea of prepackaged distributions for normal,
non-developer users, the problem I see with many "big" Emacs projects
(like TinyTools, CEDET, JDEE, etc) is that they are much of an
all-or-nothing. You install one of them, you are no longer in Emacs,
but someone's pet idea of what Emacs should look like (yeah, even if
they have a ton or two of customization options). Nothing bat per se,
but I already have my pet Emacs and we've learnt to live with each
other, thanks ;-)

> It would be better if this idea was merged into Emacs. I think however
> that it has to coexist with themes in some way and perhaps themes can be
> the underlying structure for this.

Being themeable is necessary. Being non-monolithic is fundamental, IMO.

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

Re: theming

[Lennart Borgman]

Juanma Barranquero wrote:

>>I agree to whole message. I have written EmacsW32 just for this above.
>>    
>>
>
>Much as I like the idea of prepackaged distributions for normal,
>non-developer users, the problem I see with many "big" Emacs projects
>(like TinyTools, CEDET, JDEE, etc) is that they are much of an
>all-or-nothing. You install one of them, you are no longer in Emacs,
>but someone's pet idea of what Emacs should look like (yeah, even if
>they have a ton or two of customization options). Nothing bat per se,
>but I already have my pet Emacs and we've learnt to live with each
>other, thanks ;-)
>  
>
A very, very wild idea, a save excursion for loading so to say: could 
all the setting and defining functions be defadviced during loading of 
such packages in such a way that they saved old states of symbols in a 
list called say "previous-state" where there are entries for "CEDET" 
etc. Then you could just use this list to reset the values. Perhaps?

Re: theming

[Juanma Barranquero]

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

> A very, very wild idea, a save excursion for loading so to say: could
> all the setting and defining functions be defadviced during loading of
> such packages in such a way that they saved old states of symbols in a
> list called say "previous-state" where there are entries for "CEDET"
> etc. Then you could just use this list to reset the values. Perhaps?

On one hand, I think that's similar to what Luc was proposing for the
custom-themes issue.

On the other, that doesn't avoid what I'm complaining about: you
should be able to use a big package and decide which bits are useful
to you and which are not. Although on another level, look at cua, for
example: you can decide whether you want C-c, C-x, C-v bindings,
rectangles, etc. on a feature-by-feature basis. I dislike modules that
take hold of your environment (particularly the frame/window setup) or
else they refuse to cooperate.

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

Re: theming

[Lennart Borgman]

Juanma Barranquero wrote:

>On one hand, I think that's similar to what Luc was proposing for the
>custom-themes issue.
>  
>
Oh, thanks Juanma, sorry Luc.

>On the other, that doesn't avoid what I'm complaining about: you
>should be able to use a big package and decide which bits are useful
>to you and which are not. Although on another level, look at cua, for
>example: you can decide whether you want C-c, C-x, C-v bindings,
>rectangles, etc. on a feature-by-feature basis. I dislike modules that
>take hold of your environment (particularly the frame/window setup) or
>else they refuse to cooperate.
>  
>
Yes, of course.

RE: theming

[Drew Adams]

    Much as I like the idea of prepackaged distributions for normal,
    non-developer users, the problem I see with many "big" Emacs projects
    (like TinyTools, CEDET, JDEE, etc) is that they are much of an
    all-or-nothing. You install one of them, you are no longer in Emacs,
    but someone's pet idea of what Emacs should look like (yeah, even if
    they have a ton or two of customization options). Nothing bat per se,
    but I already have my pet Emacs and we've learnt to live with each
    other, thanks ;-)

    Being themeable is necessary. Being non-monolithic is fundamental

I agree 100%. This is something that would really, really help Emacs - well
after the release.

I'm guilty, myself, of having come up with such monolithic customization
packages (with and without using "Custom"). I try to update those libraries
now (when I have time), so that the result is less monolithic and plays
better with, for instance, Custom.

(One problem is, I think, that there is a natural evolution from a set of
individual .emacs settings toward a library that others can use flexibly.
I've mentioned this before. A set of guidelines for moving from the one to
the other would help.)

Anyway, I think that a general mechanism for themes that also promotes
modularity (vs monoliths) would be a great thing to have. The current Custom
facility is essentially geared toward the individual user (it updates his
custom-file), whereas what we're talking about here are packages that
customize a lot of things at once for any set of users.

And people are right to point out that "the solution" should speak not only
to Customization stuff (variables & faces), but to key bindings too. And it
might need to provide for loading and unloading redefinitions of standard
functions, as well as dealing with advice flexibly.

I don't think the task would be easy to come up with a good, general set of
theming constructs that would let people write modular, non-monolithic
custom versions of Emacs. But it would be great if it existed.

Re: theming

[Richard M. Stallman]

    Much as I like the idea of prepackaged distributions for normal,
    non-developer users, the problem I see with many "big" Emacs projects
    (like TinyTools, CEDET, JDEE, etc) is that they are much of an
    all-or-nothing. You install one of them, you are no longer in Emacs,
    but someone's pet idea of what Emacs should look like

That is right.  In order to add a feature usefully to Emacs, it has
to be done in a modular way, so that people can use it with their own
choice of other features.  If you implement five new modular features,
it is easy to add them all to Emacs.  But if you implement your own
environment that provides the same five features in a monolithic way,
we would probably never be able to add any of them, and in the long
run it will just be a fork.

Re: theming

[John S. Yates, Jr.]

On Thu, 07 Jul 2005 14:17:52 +0200, Lennart Borgman wrote:

>I agree to whole message. I have written EmacsW32 just for this above. 
>It would be better if this idea was merged into Emacs. I think however 
>that it has to coexist with themes in some way and perhaps themes can be 
>the underlying structure for this.

I do not see it as a layering issue.  It is more a plea to move away
from simple imperative customization and towards declarative expression
of policy / intent.

I imagine such choices being made by one-of selections in which the
default value would be "classic Emacs".  Thus one knob might be

  frame-usage:
    - classic Emacs
    - OneOnOne

Further, our customize framework would have to be enriched to make
default values potentially a function of a policy query.  (A simplifying
restriction would be require that all policy choices be evaluated before
loading any customizations.)

/john

Re: theming (was: Sorting of directories in dired)

[David Reitter]

On 7 Jul 2005, at 11:53, John S. Yates, Jr. wrote:

> Historically, the Emacs community has provided default behavior
> that catered to its entrenched userbase.  The answer to nearly
> any suggestion that such behavior might be awkward / unfamiliar /
> jarring to new users, especially those on platforms held in low
> regard by the entrenched userbase, is that Emacs is customizable.
> Essentially a "Let them eat cake" attitude.

One possibility to address this is to develop 'distributions'. Just  
like, say, SUSE Linux offers a GNU/Linux OS with a whole lot of  
customization and integration, you can distribute Emacs with such  
customizations. That's what I am doing with Aquamacs Emacs, where we  
can radically change the behavior in order to make it consistent with  
GUI based operating systems.

> My notion of a theme is not a named collection of configuration
> settings.  Rather it is an expression of high-level intent:
> - as much as possible behave like Window / MacOS / *nix
> - underline clickable links
> - give me single frame behavior vs something like Drew's OneOnOne

Well, these would be examples of what I would understand as 'themes'.

I have implemented the single frame behavior (it takes more than  
OneonOne to do that), for example.
And if I understand correctly what themes are supposed to do, I  
cannot but agree with you that the currently planned collections of  
customization settings won't do the job for efforts to change the  
user interface (point 2 below). Themes make some headway though  
(point 1):

1. Aquamacs changes a lot of default customization settings, and it  
also ensures that the user's actual customizations are noted as such  
and saved - by setting the 'standard-value property whenever a  
customization variable is set. That way we ensure that the user can  
still customize whatever - it's just the defaults that are changed. A  
lot of hooks are used, but they could be handled as customization  
variables.
Making this process a bit easier, making it easier for the user to  
undo some of these new 'defaults'  by defining groups of  
customizations in themes would certainly be desirable.

2. However, over the last two or three months or so, Aquamacs has  
come to do much more than that. It blatantly redefines and advises  
functions, something which can only be undone by means of extra  
customization variables that are checked by the new functions. In  
addition to that, we patch the c core and one or two of the .el files  
in order to either implement needed additional functionality or (on  
the Carbon port side) to modify functionality. In addition to that,  
several support files in the original package are modified, others  
added (converted manuals). [I make an effort to contribute changes,  
in particular bugfixes, where I see fit - it's not a competing fork.]

CONCLUSION:
We cannot realize your points with collections of customization  
settings. The changes are much more profound.
Therefore, there is another consideration that becomes more important:
Makers of a distribution like Aquamacs would really need a stable,  
relatively bug-free release. We're shooting at a moving target  
otherwise.

Re: theming

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> I have implemented the single frame behavior (it takes more than
> OneonOne to do that), for example.
> And if I understand correctly what themes are supposed to do, I
> cannot but agree with you that the currently planned collections of
> customization settings won't do the job for efforts to change the
> user interface (point 2 below). Themes make some headway though
> (point 1):
>
> 1. Aquamacs changes a lot of default customization settings, and it
>    also ensures that the user's actual customizations are noted as
>    such  and saved - by setting the 'standard-value property whenever
>    a  customization variable is set. That way we ensure that the user
>    can  still customize whatever - it's just the defaults that are
>    changed. A  lot of hooks are used, but they could be handled as
>    customization  variables.
> Making this process a bit easier, making it easier for the user to
> undo some of these new 'defaults'  by defining groups of
> customizations in themes would certainly be desirable.
>
> 2. However, over the last two or three months or so, Aquamacs has
>    come to do much more than that. It blatantly redefines and advises
>    functions, something which can only be undone by means of extra
>    customization variables that are checked by the new functions.

Those customization variables can have a default value that lets them
cause different behavior only when under the Aquamacs theme.

So I don't see this as a principal problem once themes work properly.

> In addition to that, we patch the c core and one or two of the .el
> files in order to either implement needed additional functionality
> or (on the Carbon port side) to modify functionality. In addition to
> that, several support files in the original package are modified,
> others added (converted manuals). [I make an effort to contribute
> changes, in particular bugfixes, where I see fit - it's not a
> competing fork.]

It is a competing fork in the manner that users are not able to make
it work like standard Emacs with minimal effort.  That means that the
Aquamacs distribution is only useful for people that don't prefer
standard Emacs behavior.

That's not a good state of affairs.  If Aquamacs were
theme-controlled, one could easily fold the whole kaboodle back into
the main core, and thus people, say, used to Aquamacs could get the
same behavior under Windows, and there would be no reason to
distribute competing binaries for MacOSX.

> CONCLUSION:
> We cannot realize your points with collections of customization
> settings. The changes are much more profound.

I still don't see what would prohibit those changes from being folded
back into Emacs once they are properly controlled by a theme.

> Therefore, there is another consideration that becomes more
> important: Makers of a distribution like Aquamacs would really need
> a stable, relatively bug-free release. We're shooting at a moving
> target otherwise.

With regard to theme support, fixing the target right now seems
incompatible with both stable (as it would need to get changed
afterwards, anyway) and relatively bug-free.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: theming

[David Reitter]

On 7 Jul 2005, at 15:20, David Kastrup wrote:

>> Making this process a bit easier, making it easier for the user to
>> undo some of these new 'defaults'  by defining groups of
>> customizations in themes would certainly be desirable.

In Aquamacs, this is already the case for many customizations.
For some other stuff - for example the pre-installed fontsets and  
changed menus - this is not possible. That's where we usually tell  
people to use a standard Carbon Emacs.

>> 2. However, over the last two or three months or so, Aquamacs has
>>    come to do much more than that. It blatantly redefines and advises
>>    functions, something which can only be undone by means of extra
>>    customization variables that are checked by the new functions.
>>
>
> Those customization variables can have a default value that lets them
> cause different behavior only when under the Aquamacs theme.
>
> So I don't see this as a principal problem once themes work properly.

Yes, but what about re-definitions of existing functions?
Defadvice them and put a conditional in the defadvice?

> It is a competing fork in the manner that users are not able to make
> it work like standard Emacs with minimal effort.  That means that the
> Aquamacs distribution is only useful for people that don't prefer
> standard Emacs behavior.

Indeed, we explicitly target people who aren't happy with the  
standard behavior. That's the whole point.

> That's not a good state of affairs.

Hmm, I for my part like variety.

> If Aquamacs were
> theme-controlled, one could easily fold the whole kaboodle back into
> the main core, and thus people, say, used to Aquamacs could get the
> same behavior under Windows, and there would be no reason to
> distribute competing binaries for MacOSX.

Well, that would be even better and a long-term goal.
When themes work reliably and are well documented, one could work on  
that.

However, as long as the (IMHO sensible) patches that Seiji Zenitani  
and I have provided (which only pertain to the OS X version) don't  
find their way into the core or get formally rejected with reasons  
given, there's little one can do to turn Aquamacs an add-on package.

Re: theming

[Stefan Monnier]

>> Those customization variables can have a default value that lets them
>> cause different behavior only when under the Aquamacs theme.
>> 
>> So I don't see this as a principal problem once themes work properly.

> Yes, but what about re-definitions of existing functions?
> Defadvice them and put a conditional in the defadvice?

Don't defadvice.  Instead, change the original code.  Of course that means
coming up with a clean customization and convincing us that we should
adopt it.

> However, as long as the (IMHO sensible) patches that Seiji Zenitani and
> I have provided (which only pertain to the OS X version) don't find their
> way into the core or get formally rejected with reasons given,

I'm also surprised that there haven't been any response either way to these
patches.  They seem to provide desirable features, although I can't judge
the code.


        Stefan

Re: theming

[Richard M. Stallman]

    > However, as long as the (IMHO sensible) patches that Seiji Zenitani and
    > I have provided (which only pertain to the OS X version) don't find their
    > way into the core or get formally rejected with reasons given,

Mac-only patches are looked at only by the people that are interested
in Macs.  It's up to them.

There is, however, one rule: if something goes beyond merely adapting
Emacs to the Mac, and provides an additional Emacs feature, then it
must be implemented in general--not for the Mac alone.  (The same rule
applies to Windows.)  Our aim is to replace proprietary software,
not to enhance it.  And GNU Emacs is part of the GNU operating system.

Thus, a hypothetical feature that worked only on MacOS would be an
enhancement to non-free software, and thus ethically unacceptable.
The right way to do a new feature is so that it works on the GNU
system also.

I don't know what those specific patches do, and I don't know
whether this rule applies to them or not.  I'm mentioning it now
so that it won't be forgotten.

Re: theming (was: Sorting of directories in dired)

[David Reitter]

On 7 Jul 2005, at 19:39, Robert J. Chassell wrote:

> Quick question:  does Aquamacs require changes in the C code for just
> in the Emacs Lisp?

As stated in my original post: "we patch the c core".
But the vast majority of changes comes from .el packages (in site- 
lisp). Other distributions such as Carbon Emacs supply Lisp code in  
the same way.

> If the former, you need to build Emacs differently.

We are building Emacs slightly differently. We're also planning to  
precompile more of our stuff into a dumped Emacs binary, in order to  
speed up startup time.

- D

Re: theming (was: Sorting of directories in dired)

[David Reitter]

On 7 Jul 2005, at 13:22, David Reitter wrote:

> I have implemented the single frame behavior (it takes more than  
> OneonOne to do that), for example.

As I've been asked to clarify this: We define a range of additional  
functions, such as one to delete a buffer when its window is deleted,  
and delete the frame with it if necessary (and appropriate), or to  
decide when to open a new window (instead of a brand-new frame). We  
also advise switch-to-buffer and pop-to-buffer.
This code works on top of OneOnOne by Drew Adams. OneOnOne - to be  
exact: a subset of its functionality - has replaced an earlier  
(rather unsophisticated) implementation of frame-opening behavior in  
a very early Aquamacs version, because it is nicely structured and  
mature. Drew has done an awesome job in fixing things I wanted to see  
optimized so that we could integrate OneOnOne (including a selective  
version of the frame-fitting behavior provided by fit-frame.el) with  
other code.

OneOnOne and a number of other packages that get used can be found here:

http://www.emacswiki.org/cgi-bin/wiki/DrewsElispLibraries

In this discussion, this should serve as an example that packages  
that change the UI often need to make extensive modifications - much  
more than tweaking a few existing customization variables.

Re: theming (was: Sorting of directories in dired)

[Richard M. Stallman]

I'm not enthusiastic about Aquamacs because it seems to be headed in
the direction of being an alternative to Emacs rather than a
contribution to it.  You have a right to do this, but helping people
do this is not the main goal of Emacs development.

Re: theming (was: Sorting of directories in dired)

[Richard M. Stallman]

    My notion of a theme is not a named collection of configuration
    settings.  Rather it is an expression of high-level intent:

Aren't themes generally named collections of settings?
I thought that's what "theme" means.

    - as much as possible behave like Window / MacOS / *nix

Maybe that could be implemented as named collections of settings.
Or maybe it needs to be something more complex, like CUA mode.
We can certainly have things like CUA mode, but that doesn't
say anything about what themes should do.

    - underline clickable links

That doesn't need to be a named collection of settings
because it is just one setting.

    - give me single frame behavior vs something like Drew's OneOnOne

I'm not sure what that means, but if Emacs supports it, it would
be a single option, not a theme.

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?