[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36729: 27.0.50; Unclear total in directory listing
From: |
Mattias Engdegård |
Subject: |
bug#36729: 27.0.50; Unclear total in directory listing |
Date: |
Sun, 21 Jul 2019 20:36:15 +0200 |
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.