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

[Zoltan Somogyi]

On 2023-05-22 17:15 +10:00 AEST, "Julien Fischer" <jfischer at opturion.com> wrote:
>> 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.
> 
> Doesn't that defeat the point of having a limit in the first place?

Whether it does or not depends on what the reader thinks the limit means
in the first place. Thankfully, there is no ambiguity on this point, because
the meaning of the limit was explained in a crystal clear manner by the original
author of this predicate (a fellow with the login id "zs" :-) in *zero* characters
just before the predicate declaration :-(

If a reader takes the "limit" to mean "every character after the limit will be discarded",
then (a) the current implementation already violates this expectation, and (b) as you
yourself say, meeting this expectation can't work reliably unless you teach the
Mercury library about such things as combining characters. (If it weren't for this issue,
I would have preferred option B over A.)

If a reader takes the "limit" to mean "what is the max width to which values in this
column get padded to?", then option A works. If e.g. a column's limit is 40, but
some strings in that columns are longer, then most rows will still have that column
being formatted to be 40 chars wide, and the only rows in which this column
will be wider than that will the rows in which the value in that column is itself
longer than 40. This wouldn't be true without the limit.

> The only current user of format_table_max within the Mercury system
> appears to be the mslice tool (via mdbcomp/slice_and_dice.m).

Yes, the commit that added format_table_max said it was for slicing.

> While
> it's not particularly clear, I think the intention was to truncate
> overlong columns.

Agreed.

> I agree with Peter, it's not really something that belongs in the
> standard library

If I had to vote whether format_table and format_table_max should be added
to the standard library today, I would vote "no". But , given that they have been there
for 16 years, and people may be using them, I also vote "no" to removing them.

> since doing it properly requires (1) more Unicode
> support than the stdlib currently has and (2) knowledge of the font
> being used.  (The world was a bit more ASCII when Ian originally wrote
> all that.)

It was a *lot* more ASCII, with a side order of EBCDIC :-(, though the wars
for characters 128-255 had already begun.

> s/Nth/N'th/ (which is what we use almost everywhere else in the library documentation).

WIll fix.

Zoltan.