[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


reply via email to

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