RE: patch for Dired second header line info

[Drew Adams]

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