Re: [Nmh-workers] 1.7's putnum drops data if too close to end of line?

[Ralph Corderoy]

Hi David,

> The change was intentional, IIRC.  Better to truncate than show part
> of a number.

Right, back in 2014, I think.

> The parentheses in your format would reveal it, but without them, the
> output could be misleading with truncation.

This reproduces Tom's experience AIUI.

    $ fmttest -raw -forma '<%(void(compval{text}))%(putnum{text})>' \
    >     -outsize 5 1 22 333 4444 55555 666666
    <1>
    <22>
    <333>
    <4444
    <>
    <>
    $

What surprises me is after the `55555' gets dropped because it won't
fit, the format string continues to be processed so the `>' appears.
I'd expect "whole" things to be appended to the end of the output,
stopping when one is too big.  Otherwise, one could imagine a set of
`flags' being conditionally output in a defined order and `alpha delta'
stating `charlie' isn't set, but in fact it just couldn't fit.

> I just noticed that kilo and kibi don't truncate.

I expect there's others.  Is the interface to formatters wrong here?
They're expected to each track if there's room for their output.  It
would seem simpler if they were each told how much space was left but
were allowed to overflow.  This would make some of them trivial and
others that would do lots of work could bother to check so as to
short-cut some of it.

On return, the caller checks if they overflowed and either erases their
addition or truncates it, depending, perhaps, on a flag set in the
format.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy