On Friday, June 24, 2005 at 6:45:44 PM +0200, Hrvoje Niksic wrote:
> input for other applications, which is very hard with the thousand
> separators.
Pasting is very hard, parsing is not. An app running wget can easely
parse it's output, whatever it is. If not directly then thru a wrapper.
The problem is only with "side-apps" where user must copy/paste. How
frequently is that used?
Removing separators will break existing apps parsing wget's output.
Such apps exist?
> Alain Bench <[EMAIL PROTECTED]> writes:
>> Humans can have habit to look at exact unit size, or rounded
>> kilo/mega/tera size, or both.
> omitting the thousand separators merely removes redundancy, not useful
> information.
That's true only if you assume the user analyses the /unit-size/ and
/kmt-size/ as a whole, as a unique info. But that's not always the case.
One may well look only at /unit-size/. Without seps, this user is forced
to count digits, or to look additionally to /kmt-size/, and do some
brainwork to find corresponding order of magnitude. For this user, sep
removal removes readability.
> If the users were so used to separators, they would surely request
> them in other programs, such as `ls', `du', or `df'?
Those 3 commands print numbers in right-aligned columns: The
ergonomic need for seps is a little lower. And the "ls -l" filename
truncation on 80 wide terms might be seen as a bigger annoyance: 3 seps
added in size would mean 3 chars less in filename. And legacy behaviour
*MUST* absolutly be retained for such old, widely used, and frequently
machine-parsed commands.
But anyway I would personally love to see separators here too.
[localization]
> You can make a case that the correct character and layout should be
> used for digit grouping when it is deployed, but I don't see how you
> can argue that grouping *must* be used in all applications!
I agree. There are cases where localized grouping and even grouping
alone are useless or harmfull: Each time the only or primary destination
of a number is another app.
But when the intendend reader is human, localized grouping *should*
be used. Unless a bigger unavoidable danger interferes. That's my humble
opinion, but I believe it's also some more general ergonomic principle.
I am able to buy the small advantage over code complexity ratio
argument you once explained. But I somewhat regret having to buy it.
BTW my "locale thousands_sep" gives a " " non-breaking space, and
"locale decimal_point" gives a "," comma.
> As for localization, I'm not against it. The argument was that, where
> possible, I prefer the output of applications to remain parsable.
So we disagree only on the balance. I'd say output to humans should
be localized as much as possible, unless this creates a really serious
problem for the machine parsing secondary usage.
Where incompatible, human and machine output may be separated. Say
on option, or like GnuPG --status-fd simultaneously: Human reads
stdout/err, while machine parses another fd. That's material for present
debate, not my wish for wget.
> I consider the ISO 8601 date format a clear advantage over the
> asctime() format.
;-) Good example: I *hate* having to read 8601 dates. Nearly as much
as having to read those other dates, localized or not, with month/day
ambiguity. MHO only, here: I know some people love 8601.
Bye! Alain.
--
« if you believe subversive history books, I've got a bridge to sell you. »
