Re: 'struct window' cleanup #2

[Eli Zaretskii]

> Date: Tue, 26 Jun 2012 09:26:52 +0200
> From: martin rudalics <address@hidden>
> Cc: Stefan Monnier <address@hidden>,
>       Emacs development discussions <address@hidden>
> 
>  >> 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.

Why a "hack"?  Lisp object are good precisely for this reason: that
you can give them values of different types of object.

> Anyway, window_end_pos and window_end_vpos are the more
> promising candidates (if Eli agrees).

I don't object.  But if we think that Lisp integers cause any
significant slowdown during GC, we could special-case them in
mark_object, because that is a no-op for integers.  That would be less
work and less potential bugs.

>  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?

No, there's no code anymore that sets it to nil.