From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: patch for Dired second header line info Date: Sun, 2 Mar 2008 00:05:09 -0800 Message-ID: <000f01c87c3c$22f7db50$0600a8c0@us.oracle.com> References: <000101c87b38$1dcd2db0$0600a8c0@us.oracle.com> <87fxv9zxqv.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1204445243 16720 80.91.229.12 (2 Mar 2008 08:07:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Mar 2008 08:07:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 02 09:07:49 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JVjEb-0006xY-G0 for ged-emacs-devel@m.gmane.org; Sun, 02 Mar 2008 09:07:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVjE4-0000AA-NH for ged-emacs-devel@m.gmane.org; Sun, 02 Mar 2008 03:07:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JVjE0-00007Y-DK for emacs-devel@gnu.org; Sun, 02 Mar 2008 03:07:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JVjDz-00006t-VT for emacs-devel@gnu.org; Sun, 02 Mar 2008 03:07:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVjDz-00006b-OJ for emacs-devel@gnu.org; Sun, 02 Mar 2008 03:07:11 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JVjDz-0004E9-40 for emacs-devel@gnu.org; Sun, 02 Mar 2008 03:07:11 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JVjDr-000413-FR for emacs-devel@gnu.org; Sun, 02 Mar 2008 03:07:03 -0500 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m2286sPF010006; Sun, 2 Mar 2008 02:06:54 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m226Hkro006751; Sun, 2 Mar 2008 01:06:53 -0700 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3596774571204445109; Sun, 02 Mar 2008 00:05:09 -0800 Original-Received: from dradamslap1 (/141.144.64.82) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 02 Mar 2008 00:05:09 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87fxv9zxqv.fsf@jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach8FbQ7CqOui0KsS3WrjWzBR0zS7QAH+dYQ X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by mx20.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:91047 Archived-At: > > The second header line in a Dired buffer currently looks like this: > > > > total used in directory 49439 available 56233408 > > > > Attached is a patch (for `files.el' and `ls-lisp.el') that > > changes that text to this: > > > > files 691 space used 49439 available 56233408 > > Are you sure this change will not break other packages that > rely on the first word `total' at the beginning of a dired > buffer? How could I (or anyone) be sure of that? Who knows what some package might rely on? > It seems it would be safer to leave it as is, and > add new information to the end of this line like: > > total used in directory 49439 available 56233408 files 691 Go for it, if you think that's right. I think that the text I used is clearer - see my comments about "total" and "used"/"available". And if some package were to break because of my proposed change, then we would fix the code as needed. If things are so fragile that we don't dare change text such as this, then the design is wrong. In fact, the right way to do this kind of thing is to use a function or variable instead of hard-coded text. But a change to do that might also break some package somewhere. (if omelette (break eggs)) But do as you like. > Also I think instead of displaying the number of files listed > in the current dired buffer, more useful would be to display > the total number of files in the current directory. There are > features that hide files in the dired buffer (e.g. > dired-omit-mode), so displaying the total number of > files will be helpful for users to see that there are more > hidden files. I disagree - it's a feature, not a bug, to see how many files are currently visible. For example, if I use Dired with wildcards, I want to see how many matching files there are. If I hide the files with extension `elc', I want to see how many files are left. And so on. The figure should reflect the current display state. BTW, I did not check until now, but that is also apparently the approach Windows Explorer uses (FWIW). If you hide system files, for instance, the file count excludes them. > This also will simplify the implementation of the feature you propose, > so instead of a new function `count-dired-files' you can just use > (length (directory-files dir nil t)) I purposefully avoided that approach, preferring to have it tell you how many files were currently visible. But do whatever you like with it. Whatever semantics you choose, the doc needs to make clear what the meaning is. Likewise for the other fields. Actually, instead of changing the patch, please ignore it and leave the code as it is. At least that way my extension will continue to work for me. ;-)