Re: [lmi] Correctness and performance of varying column width mode in the census view

[Greg Chicares]

On 2020-05-27 16:22, Vadim Zeitlin wrote:
> 
>  I'm struggling with choosing the right two out of the following three
> goals for the automatic column fitting in the census view:
> 
> 1. Correct.
> 2. Fast.
> 3. Simple.
> 
> and would like to ask for your help with determining the ones to pursue.

If we define correctness as
 - a valid input file always produces valid reports, and
 - invalid input never produces invalid reports
then that type of correctness is paramount. But I think you're using
a different definition here.

Suppose we have a field containing a person's name, say, "John Brown",
and (pretending this is monospace ASCII) those ten letters are rendered
in a column of width eleven (pretending that the column separator is a
single ASCII space). Now the end user changes that one field, in that
one column, to "Sojourner Truth". If we don't change the column width,
the screen shows "Sojourner" because that's all that fits, " Truth"
being truncated; is that truncation your operative definition of
incorrectness?

I'm hoping that's all it is, because I think that truncation is not
really unreasonable, as it's what spreadsheet programs do. AIUI,
for spreadsheets, "resize column widths" is a verb--whereas lmi has
(at least until now) offered such a behavior as a sticky mode, in
which the verb is called whenever any contents change (in that mode).

While that "always resize everything whenever anything changes" mode
does have a certain charm for a tiny census, it seems far too costly
for a large number of columns and rows.

AFAICS lmi's GUI presents it as a verb. IOW, there are separate toolbar
buttons for "fixed" and "variable", rather than a single button that's
either depressed or not. Thus, the stickiness of the notional mode is
just an internal artifact that we can and should eradicate.

Does that answer all your questions?