[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'struct window' cleanup #2
From: |
martin rudalics |
Subject: |
Re: 'struct window' cleanup #2 |
Date: |
Tue, 26 Jun 2012 09:26:52 +0200 |
>> How about window_end_pos, window_end_vpos and window_end_valid?
>
> xdisp.c assigns w->buffer to w->window_end_valid, so it may be tricky.
> I suppose window_end_valid may be a bitfield; so, NILP
> (W->window_end_valid)
> becomes !W->window_end_valid, EQ (w->window_end_valid, w->buffer)
> becomes W->window_end_valid, etc.
Indeed. Looks like a hack to detect whether the window still shows the
same buffer. Anyway, window_end_pos and window_end_vpos are the more
promising candidates (if Eli agrees). Can you see whether the part
/* When splitting windows or for new windows, it happens that
redisplay is called with a nil window_end_vpos or one being
larger than the window. This should really be fixed in
window.c. I don't have this on my list, now, so we do
approximately the same as the old redisplay code. --gerd. */
&& INTEGERP (w->window_end_vpos)
in xdisp.c still makes sense? IIUC window_end_vpos is always an
integer.
martin
- 'struct window' cleanup #2, Dmitry Antipov, 2012/06/25
- Re: 'struct window' cleanup #2, John Wiegley, 2012/06/25
- Re: 'struct window' cleanup #2, Paul Eggert, 2012/06/25
- Re: 'struct window' cleanup #2, Stefan Monnier, 2012/06/25
- Re: 'struct window' cleanup #2, Dmitry Antipov, 2012/06/25
- Re: 'struct window' cleanup #2, martin rudalics, 2012/06/25
- Re: 'struct window' cleanup #2, Eli Zaretskii, 2012/06/26
- Re: 'struct window' cleanup #2, Dmitry Antipov, 2012/06/26
- Re: 'struct window' cleanup #2, Eli Zaretskii, 2012/06/26
- Re: 'struct window' cleanup #2, Stefan Monnier, 2012/06/26
- Re: 'struct window' cleanup #2, Eli Zaretskii, 2012/06/26
- 'struct window' cleanup #3, Dmitry Antipov, 2012/06/27
- Re: 'struct window' cleanup #3, Stefan Monnier, 2012/06/27
- Re: 'struct window' cleanup #3, Eli Zaretskii, 2012/06/27