ken wrote:
%(metric(size))
And that could be usable in scan formats and the like. Not in love with
the function name, so other suggestions are welcome.
If you're not up for coding that, I could get to it, but it might be
a few days before it would be done.
i'll take a look at it.
There are comments at the beginning of fmt_compile.c which explain the
basics, so if you want to tackle it before me that should get you started.
To give you an idea, the functable entry for my proposed %(metric) function
would look something like:
{ "metric", TF_EXPR, FT_LS_METRIC, 0, TFL_PUTS },
(You'd have to define FT_LS_METRIC, of course).
yes, the comments got me going. not too hard to get it basically
working.
but i was just sitting eating lunch, trying to decide how clever to
be: currently mhlist converts "2563123" bytes to "2503K", which i've
always found to be somewhat ugly -- i'd prefer a small number of M
instead of a large number of K. do we need to stick with that format?
but if we don't, should the conversion use 1024 ("2.4M") or 1000
("2.6M") as the divisor? and of course that leads to MB vs. MiB.
and how many digits should there be after the decimal? sigh.
all of which makes me lean to the status quo.
thoughts?
paul
----------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 57.9 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers