bug#36729: 27.0.50; Unclear total in directory listing

["Mattias Engdegård" <mattiase@acm.org>]

21 juli 2019 kl. 16.29 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> (Your reaction seems to imply that I said something silly.  Did I?)

Absolutely not, your comment was most reasonable. It was just my honest reaction of exasperation for not being able to fix such a stupid detail properly.

> Your original report was about the unclear units of the value, so a
> useful clarification would be to tell something about those units.
> That is what I had in mind when I suggested a doc clarification.

Quite, but while we could write that the value might be this or that, it wouldn't actually help the user unless he or she is so well-informed that no explanation is needed. As we all know, good design should not need explaining.

> We already have ls-lisp.el.  It isn't used on platforms where 'ls' is
> available because AFAIK using 'ls' is faster.

Is that is still noticeable on modern systems, or just for very big and/or recursive listings?

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

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

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.