unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juri Linkov'" <juri@jurta.org>
Cc: emacs-devel@gnu.org
Subject: RE: patch for Dired second header line info
Date: Sun, 2 Mar 2008 00:05:09 -0800	[thread overview]
Message-ID: <000f01c87c3c$22f7db50$0600a8c0@us.oracle.com> (raw)
In-Reply-To: <87fxv9zxqv.fsf@jurta.org>

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






  reply	other threads:[~2008-03-02  8:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-01  1:03 patch for Dired second header line info Drew Adams
2008-03-01 13:31 ` Richard Stallman
2008-03-01 16:31   ` Drew Adams
2008-03-01 23:09     ` Richard Stallman
2008-03-02  2:55 ` Juri Linkov
2008-03-02  8:05   ` Drew Adams [this message]
2008-03-02 14:36     ` Juri Linkov
2008-03-02 16:27       ` Drew Adams
2008-03-02 17:49         ` Drew Adams
2008-03-02 17:57           ` Juri Linkov
2008-03-02 18:56             ` Drew Adams
2008-03-02 19:06               ` Drew Adams
2008-03-03  0:47                 ` Drew Adams
2008-03-03 18:27             ` Richard Stallman
2008-03-03 21:45               ` Stefan Monnier
2008-03-03 22:29                 ` Drew Adams
2008-03-04 17:38                   ` Richard Stallman
2008-03-04 19:44                     ` Drew Adams
2008-03-04 22:28                       ` Drew Adams
2008-03-05 21:33                       ` Richard Stallman
2008-03-03 18:27           ` Richard Stallman
2008-03-03 19:01             ` Drew Adams
2008-03-02 17:56         ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000f01c87c3c$22f7db50$0600a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@jurta.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).