From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.pretest.bugs,gmane.emacs.devel Subject: RE: Sorting of directories in dired Date: Thu, 7 Jul 2005 15:53:58 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1120777059 30648 80.91.229.2 (7 Jul 2005 22:57:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2005 22:57:39 +0000 (UTC) Original-X-From: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Fri Jul 08 00:57:39 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DqfJ0-0001QL-Vg for gebp-emacs-pretest-bug@gmane.org; Fri, 08 Jul 2005 00:57:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DqfKO-0008GS-Mb for gebp-emacs-pretest-bug@gmane.org; Thu, 07 Jul 2005 18:58:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DqfJa-00080n-F6 for emacs-pretest-bug@gnu.org; Thu, 07 Jul 2005 18:57:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DqfJU-0007yY-GY for emacs-pretest-bug@gnu.org; Thu, 07 Jul 2005 18:57:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DqfJT-0007xh-On; Thu, 07 Jul 2005 18:57:47 -0400 Original-Received: from [148.87.122.33] (helo=rgminet04.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DqfMP-0007Gw-CW; Thu, 07 Jul 2005 19:00:49 -0400 Original-Received: from rgminet04.oracle.com (localhost [127.0.0.1]) by rgminet04.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j67Ms1mq005016; Thu, 7 Jul 2005 16:54:01 -0600 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet04.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j67Ms0Mw004983; Thu, 7 Jul 2005 16:54:00 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j67Ms01d009714; Thu, 7 Jul 2005 16:54:00 -0600 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j67Mrx3W009706 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 7 Jul 2005 16:54:00 -0600 Original-To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-BeenThere: emacs-pretest-bug@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: emacs-pretest-bug.gnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Errors-To: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.pretest.bugs:8361 gmane.emacs.devel:40606 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40606 > 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.