Re: feature/icomplete-vertical

[João Távora]

Gregory Heytings <ghe@sdf.org> writes:

>>> If an application wants to fit the buffer in the window, or display
>>> some hint about truncation, it's the application's business to do
>>> these things.
>>
>> I guess you can argue that, but this implies there are ways to
>> predict truncation (since being notified of it seems to be what
>> you're opposed to).
>>
>> So how is the application to know if its n lines, of lengths L =
>> {l1, ..., li, ..., ln}, it wants to display (not necessarily by
>> buffer insertion) in the mini-window need truncation and starting in
>> which line?  Does it need to perform calculations with
>> max-mini-window-height? If so, is there a "canonical" way to perform
>> these calculations that accounts for fontsizes, frame widths, etc?
>> To be clear, I find this information useful for other domais,
>> notably designing the way the Eldoc should show information in the
>> echo area.
>>
>
> This is feasible, but IMHO very (and needlessly) difficult.  Basically
> you need to work with pixel dimensions, and recalculate everything
> manually: first calculate the (maximal) size of the miniwindow (given
> the user preferences, in particular max-mini-window-height), then
> calculate the size of its contents with window-text-pixel-size.  You
> should add one character (or line) at at time, and recalculate the new
> size each time.

Yes, as far as I understand, in the general case, it must be one
character at a time, since each character might have a different pixel
width.  At some point there is a cutoff and things are not displayed
anymore.  I was hoping that that knowledge, which is held somehere in
the system at some point, could be imparted to the application.

Anyway, whatever the mechanism (notification or painstaking
calculation), we should first write a function that does this.  That is
the bugfix in my opinion.  Then we can work on simplifying that
function's implementation, if it turns out to be slow or problematic.

João