[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35756: [PATCH] file-size-human-readable: fix glitches and add option
From: |
Mattias Engdegård |
Subject: |
bug#35756: [PATCH] file-size-human-readable: fix glitches and add optional space |
Date: |
Wed, 15 May 2019 22:02:50 +0200 |
The `file-size-human-readable' function is very useful but could do with some
better formatting: normally, a space goes between the number and unit; you
don't write '3kg' or '25m/s' but '3 kg' and '25 m/s' (sloppy British newspapers
notwithstanding). We could add an optional argument so that the caller can use
the spacing of preference; the default should probably be no space, for
compatibility.
For some reason, only the `iec' mode adds an actual unit (B) to the result; the
default and `si' modes just append a scale prefix. Of course a user can append
the unit of choice, as in:
(concat (file-size-human-readable size 'si) "B")
which permits the function to be used for other units than bytes, such as
"bit/s" (although the name makes it clear that it is intended for file sizes
only). However, spacing complicates things, since we want
(file-size-human-readable 14 'si " ")
to return "14", not "14 ", but the latter is what we need when appending the
unit.
I'm not sure how to fix this. We could add another optional argument, UNIT say,
which is the string to use as unit, defaulting to "B" in `iec' mode and the
empty string otherwise. The attached patch does not address this.
There is also a small glitch to be fixed:
(file-size-human-readable 3 'iec) => "3iB"
which of course should be "3B".
0001-Optional-space-in-file-size-human-readable.patch
Description: Binary data
- bug#35756: [PATCH] file-size-human-readable: fix glitches and add optional space,
Mattias Engdegård <=