Re: Alternate design [Was: Re: [RFC] some reworking of struct window]

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Right, we could probably replace window_type by a boolean, used only for
>> the "child is a window" case and indicating whether the split is
>> vertical or horizontal.
> Since at least two people suggests such an alternate design, here is it.

The main motivation, for me, is to eliminate "invalid states"
(e.g. window_type=LEAF but the content is a window).

> -    /* The buffer displayed in this window.  Of the fields vchild,
> -       hchild and buffer, one and only one is non-nil unless the window
> -       is dead.  */
> -    Lisp_Object buffer;
> +    /* Payload may be buffer, window, or nil.  */
> +    Lisp_Object payload;

For me, `payload' is associated with transport (or communication), so it
sounds a bit odd here.  But I won't oppose it (whereas I do oppose "object").

> +    /* Non-zero if this window is internal, e.g. used in either
> +       horizontal or vertical combination.  */
> +    unsigned combination : 1;

Isn't that redundant with BUFFERP (payload)?
I actually prefer the enum form than this one (which adds a fourth
state, basically, instead of removing invalid states).
But I think we can eliminate this `combination', which is better than either.

> +#define WINDOW_LEAF(W) \
> +  (!(W)->combination)

I'd call it WINDOW_LEAF_P since it's a predicate (returns a boolean).

> +#define WINDOW_HORIZONTAL_COMBINATION(W) \
> +  ((W)->combination && (W)->horizontal)

I think this should be (eassert (WINDOWP ((W)->payload)), (W)->horizontal)

> +#define WINDOW_VERTICAL_COMBINATION(W) \
> +  ((W)->combination && !(W)->horizontal)

#define WINDOW_VERTICAL_COMBINATION(W) (!WINDOW_HORIZONTAL_COMBINATION(W))

And we probably should call them both with a "_P" suffix.


        Stefan