[m-rev.] request for opinions: string.format_table_max output

[Zoltan Somogyi]

 This diff adds the first test in the test suite of format_table_max.
For input for which format_table output

aaa|áaȧ|1111111|¹½⅓¼⅕⅙⅛|  1,300,000.00

format_table_max output

aaa|áaȧ|1111111|
              ¹½⅓¼⅕⅙⅛|
                    1,300,000.00

It is probably not visible in this email (but is visible in the diff)
that each table column here does start at the correct offset from
the start of the line, which is what the current code is trying to do.
My question is: *should* it try to do this? I can see two alternatives
that could be better in some respects.

A Don't split lines even if some columns are over their width limit.
  Instead, just let such fields take more than their usual maximum width,
  resulting in the same output as if somedid JJ in vim on the above
  three-line output.

  Plus: each conceptual line gets output on one actual line. Minuses:
  an overlong column will move later columns to the right, and the
  is no way enforce an overall line limit.

B If *any* column is overlong, then take as many characters from each column
  as that column's limit allows, and construct an output line as usual from that,
  then repeat the process with any leftover characters as needed.

  Pluses: fully enforces column width limits; puts initial parts of each column
  on same line. Minus: breaks the text of overlong columns, possibly at points
  that are suboptimal for understanding.

Should we switch to either option A or B? Alternatively, should we have
different functions for A, B and the status quo?

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.ft
Type: application/octet-stream
Size: 601 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20230521/cd710511/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.ft
Type: application/octet-stream
Size: 14869 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20230521/cd710511/attachment-0001.obj>