emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Sorting of directories in dired


From: Drew Adams
Subject: RE: Sorting of directories in dired
Date: Thu, 7 Jul 2005 15:53:58 -0700

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]