[m-rev.] request for opinions: string.format_table_max output
Zoltan Somogyi
zoltan.somogyi at runbox.com
Mon May 22 16:17:41 AEST 2023
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.
More information about the reviews
mailing list