bug#36729: 27.0.50; Unclear total in directory listing

[Drew Adams <drew.adams@oracle.com>]

I'm not weighing in here about most of what I see
being discussed in the thread.  And note that I
use Emacs mostly on MS Windows these days, so I
use ls-lisp (and am very grateful for it).

> I understand the history behind Dired's design: at one point in time,
> using the system `ls' was not only a way to re-use existing system
> software, but also gave performance advantages as well as presenting
> the information in a familiar way.  In addition, the `ls' output was
> more or less identical everywhere, making it easy to parse (no
> localisation, no Unicode, no MS-DOS, no fancy GNU or BSD options).

Those are 3 good reasons for Dired being based
on `ls' and its listings: (1) performance, (2)
familiarity, and (3) regularity and simplicity
of design/handling (e.g. parsing).

Another good reason is that a given user's system
`ls' command might support switches and behavior
that ls-lisp does not support.  That one you left
out, and it's the one that most directly concerns
ls-lisp.  Ls-lisp is not, and likely will never
be, a complete replacement for all of the possible
`ls' commands out there.

IMHO, Dired should continue to be based on `ls',
at least in the sense of (1) accepting, displaying,
and working with its output, and (2) accepting and
handling its most common switches.

> The `ls -l' format, in turn, hasn't changed perceptibly for 40 years,
> give or take a few -- not because it was perfect from the start but
> because nobody dared breaking scripts and shell pipelines for minor
> usability advantages.
> 
> Thus we are stuck with silly design elements like:
> - major structure indicated with a discrete 'd' in column 1
> - less-important stuff like the link count and group name prominently
>   displayed
> - the file name itself relegated to the very end as if an afterthought,
>   often going past the margin
> - disk usage counted in 512-byte physical disk sectors (but not
>   including subdirectories, that would be too useful)
> - timestamp parts separated in columns equal in importance to other
>   attributes
> - directory 'size' column almost completely useless
> - little support for file system improvements since 1975

I disagree that the "prominence" of such info is a
problem in Dired nowadays.  It is trivial to use
Dired with such info hidden, and it's trivial to
toggle, to hide/show it.  In my case, I keep details
hidden most of the time.  I typically just show them
temporarily to check the time or byte size of a file
or two.

> We can do better, while retaining the old format for those who have
> grown too accustomed to it (not meant as pejorative).
> It's just not what I had planned for in order to fix this bug.

It sounds instead like your complaint is with `ls'
itself - being 1975-ish or something.  Push to make
`ls' become the way you want it, and let Dired then
adapt to support that, if it happens.

There is a _lot_ to Dired, including use of `find'
output and the ability to show info for files and
directories from unrelated parts of the file system
in the same buffer (a little known, useful feature).

We should not be proposing a Dired replacement for
`ls' output.  (And I didn't think this bug was
supposed to be about that, anyway.)