curl progress meter human-readable unit breakage

[Fd929c2CE5fA]

I did this

This seems to be some changes in the latest version, now the number becomes very long instead of auto display the suitable unit suffix.

curl 8.17.0:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 16097M   0 96166k   0     0 17384k     0   0:15:48  0:00:05  0:15:43 20627k

curl 8.16.0:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  1 15.7G    1  228M    0     0  12.2M      0  0:21:55  0:00:18  0:21:37 12.7M

curl/libcurl version

curl 8.17.0

operating system

macos/homebrew

[bagder]

It now uses 6 characters instead of 5 before - which allows for a higher precision. Still with suitable suffixes.

[jay]

The older does look easier to read.

[bagder]

Maybe 9999 should be the largest number to show

[jay]

That would be better, however 6.9M is easier to read than 6789k in my opinion

[bagder]

Sure, and 7M is even easier. I'm not sure that is what we want though.

[Fd929c2CE5fA]

It now uses 6 characters instead of 5 before - which allows for a higher precision. Still with suitable suffixes.

I like the idea of ​​increased precision, but not at the expense of default readability, I'd rather see it implemented as an option rather than modifying and forcing the default, which makes me feel like something is broken.

--size-decimal <num> (progress size precision 0-3, default: 1)

The older does look easier to read.

Same for me.

Maybe 9999 should be the largest number to show

I think the consensus is 999.9 or 999.99 etc.
You could increase the precision after the decimal point instead of the number of digits before the decimal point.

For example: 15.719G ✅, 16097M 👎

[Fd929c2CE5fA]

Also, if we're going to talk about precision, we'd better be clear about which unit prefix we're using, we appear to be using SI (Decimal/1000), but we actually seem to be calculating values ​​in IEC (Binary/1024).

In other words, if we still use 'k', 'M', 'G', 'T', 'P' as units, please use Decimal/1000 to calculate.

If we still want to use Binary/1024 for calculation, please use 'Ki', 'Mi', 'Gi', 'Ti', 'Pi' instead.

It would also be nice to have an option allowing explicit use of SI or IEC units. Remember never to use JEDEC.

--unit-prefix-iec (use standard `IEC` prefixes， default: `SI` prefixes)

https://en.wikipedia.org/wiki/Binary_prefix
https://en.wikipedia.org/wiki/SI_prefix
https://en.wikipedia.org/wiki/IEC_80000-13

[Fd929c2CE5fA]

That would be better, however 6.9M is easier to read than 6789k in my opinion

Sure, and 7M is even easier. I'm not sure that is what we want though.

From a readability perspective, we should never use integers > 999

In other words, for a fixed 6 characters we could able have:

|     0|
|     9|
|    99|
|   999|
|    1k|
|  1.1k|
| 1.11k|
|1.111k| // perhaps better to only keep 1-2 decimal places
|   10k|
| 10.1k|
|10.11k|
|  100k|
|100.1k|
|999.9k|
|    1M|
|   10M|
| 10.1M|
|99.99M|
|100.1M|
|999.9M|
|    1G|

For comparison, also 6 characters:

|     0|
|     9|
|    99|
|   999|
|  9999|
| 99999|
|999999|
| 1000k|
| 9999k|
|99999k|
|99999k|
|  100M|
|100.1M|
|999.9M|
| 1000M|
| 9999M|
|10000M|
|99999M|

5 characters

|    0|
|    9|
|   99|
|  999|
| 9999|
|99999|
| 100k|
| 999k|
|1000k|
|9999k|
|  10M|
|10.1M|
| 100M|
| 999M|
|1000M|
|9999M|

Upon closer inspection, the precision improvement of the latter two is actually very limited, and the part where the precision is improved happens to be the part that is difficult to read.