Re: 'struct window' cleanup #3

[Dmitry Antipov <dmantipov@yandex.ru>]

On 06/27/2012 09:24 PM, Eli Zaretskii wrote:

>> 3. The check:
>>
>>      && INTEGERP (w->window_end_vpos)
>>      && XFASTINT (w->window_end_vpos) < w->current_matrix->nrows
>>
>>      is transformed to:
>>
>>      && w->window_end_vpos > 0
>>      && w->window_end_vpos < w->current_matrix->nrows
>
> I don't think this is right.  window_end_vpos is the number of the
> last glyph row of a glyph matrix, so it can legitimately be zero, when
> w->current_matrix->nrows is 1.  We need to initialize this member with
> some invalid value, like -1, if we want to distinguish between values
> we can and cannot trust.  Or maybe test window_end_valid here (to put
> our money where our mouth -- i.e. the commentary -- is ;-).
>
>>      I never get w->window_end_vpos >= w->current_matrix->nrows
>
> Try something that enlarges and then shrinks the minibuffer window.
> Or maybe split a window on a TTY.  Anyway, this does happen.
>
>>      but run into w->window_end_vpos == 0 several times.
>
> See above: it's a legitimate value.
>
>>      At this moment, I have no ideas whether Gerd was correct about
>>      fixing window.c, so this needs more detailed investigations.
>
> My gray hair taught me that Gerd is usually right.

I need more time to think on it. Nevertheless, I believe that other fields of
struct window (which aren't used in such a tricky way) may be converted
without a risk to break redisplay, and I did that in 108788 and 108790.

Dmitry