[Top][All Lists]

[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 <address@hidden>:
> (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 

> 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 

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]