[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'struct window' cleanup #3

From: Dmitry Antipov
Subject: Re: 'struct window' cleanup #3
Date: Thu, 28 Jun 2012 16:51:21 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]