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 13:35:53 -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 1120769040 10210 80.91.229.2 (7 Jul 2005 20:44:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2005 20:44:00 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org Original-X-From: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Thu Jul 07 22:43:59 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DqdCN-0000hg-98 for gebp-emacs-pretest-bug@gmane.org; Thu, 07 Jul 2005 22:42:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DqdDk-00064m-S2 for gebp-emacs-pretest-bug@gmane.org; Thu, 07 Jul 2005 16:43:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DqdCR-0005oR-EJ for emacs-pretest-bug@gnu.org; Thu, 07 Jul 2005 16:42:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DqdBZ-0005cl-IC for emacs-pretest-bug@gnu.org; Thu, 07 Jul 2005 16:41:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DqdBG-0005Rj-R7; Thu, 07 Jul 2005 16:41:10 -0400 Original-Received: from [148.87.122.32] (helo=rgminet03.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DqdCl-0005Yd-Fa; Thu, 07 Jul 2005 16:42:43 -0400 Original-Received: from rgminet03.oracle.com (localhost [127.0.0.1]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j67KZul4026313; Thu, 7 Jul 2005 14:35:57 -0600 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j67KZtLn026270; Thu, 7 Jul 2005 14:35:55 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j67KZtUD022571; Thu, 7 Jul 2005 14:35:55 -0600 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j67KZsOC022564 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 7 Jul 2005 14:35:54 -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:8358 gmane.emacs.devel:40587 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40587 > 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.