[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sorting of directories in dired
RE: Sorting of directories in dired
Thu, 7 Jul 2005 13:35:53 -0700
> 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'
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
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
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
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)
> I would like to see the commented line uncommented again, so
> variables all do what they were originally desiged to do for Windows.
If that line is uncommented, preloading will cause ls-lisp to produce
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:
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:
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
> (e.g. showing columns that make no sense outside of Unix),
> change the option values, but the default values should make
sense for each
That's not the Emacs philosophy, AFAIK. Consistent behavior across
platforms is deemed more important than consistency with other
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
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