ralph wrote: > Hi Paul, > > > it's clearly (to me, at least) not too late to change "units" to > > "kilo". kibi can be added separately. > > Ken said the code used base 2, >> 10, so the shipped files using the new > `units' should switch to kibi? Or perhaps there aren't any? (I thought > the functions were being added so marker lines could better represent > the content so they were being used there.)
summary: currently (1.6 and previous) the part marker comes from mhlist's list_content(). that code computes the size using ">> 10", and prints K/M/G/T. it avoids dealing with fractions by printing small numbers of megabytes as large numbers of kilobytes, e.g.. "1089K". when i made the marker controllable, at first the size got dropped altogether (since part size wasn't available from mh-format), and then when i realized that was a bit of a UI regression, it got added back using %(units), which does "/ 1000", and prints K/M/G/T. the default mhshow.marker then adds a 'B', resulting in KB/MB/GB/TB. ken and i had agreed that it was okay to change the format somewhat (we were specifically discussing the "1089K" thing at the time), and since i was only implementing one %(units) function, decimal seemed like a better choice than binary. %(units) prints at most one digit after a decimal point for fractional values. i'm currently planning on renaming %(units) to %(kilo), and then adding a new %(kibi), which will print Ki/Mi/Gi/Ti. i don't particularly care whether %(kilo) or %(kibi) is used in the default marker. if left to me, i'll choose %(kilo). paul =---------------------- paul fox, [email protected] (arlington, ma, where it's 47.3 degrees) _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
