Broken stats print due to #805

[jodavies]

The refactoring commit of #805 produces different output in the case of very long expression names:

#: TermsInSmall 10

* long expression name messes up stats?
Symbol x;

Local abcdefghijklmnop   = <x^1>+...+<x^100>;
Local abcdefghijklmnopq  = <x^1>+...+<x^100>;
Local abcdefghijklmnopqr = <x^1>+...+<x^100>;

.end

gives with 5.0.0:

Time =       0.00 sec    Generated terms =        100
abcdefghijklmnop         Terms in output =        100
                         Bytes used      =       2412

Time =       0.00 sec    Generated terms =        100
bcdefghijklmnopq         Terms in output =        100
                         Bytes used      =       2412

Time =       0.00 sec    Generated terms =        100
cdefghijklmnopqr         Terms in output =        100
                         Bytes used      =       2412

and with master:

Time =       0.00 sec    Generated terms =        100
abcdefghijklmnop         Terms in output =        100
                         Bytes used      =       2412

Time =       0.00 sec    Generated terms =        100
abcdefghijklmnopq         Terms in output =        100
                         Bytes used      =       2412

Time =       0.00 sec    Generated terms =        100
abcdefghijklmnopqr         Terms in output =        100
                         Bytes used      =       2412

I can fix this, but my question is: should we retain exactly the old behaviour (truncating the expression name) or allow it to use up more of the empty space before "Terms in..." ? Personally I prefer the latter, even if the stats are technically not printed in exactly the same way as previously (and in this case, what to do if the expression name doesn't fit in the 24-char space?)

According the manual, expression names longer than 16 chars are "forbidden" anyway (but work, if you are careful not to go too far over with Save).

[tueda]

I think printing names up to 24 characters before truncation would be a reasonable improvement and an acceptable change, though strictly speaking, it differs from the previous behaviour.

According the manual, expression names longer than 16 chars are "forbidden" anyway (but work, if you are careful not to go too far over with Save).

In principle, we could introduce a v3 save-file format in the future to support longer expression names. The name field could be either fixed-length (say, 64 characters) or variable-length. In either case, FORM should remain able to read both the current v2 and older v1 save files.