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

[Zoltan Somogyi]

On 2023-05-22 16:12 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> On Sun, 21 May 2023 22:18:04 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.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.
>> 
>>   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?
>> 
> 
> I think we should do A (don't split rows across lines). There will be
> situations where someone wants to do something else, but I disagree with
> including table formatting in the standard library anyway.

OK. Unless someone objects in the next few hours,
that's what I will commit.

>> +cound_and_find_max_str_length(Str, Count0, Count, PrevMaxLen, MaxLen) :-
> 
> count

Thanks for the catch.

Zoltan.