[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Alternate design [Was: Re: [RFC] some reworking of struct window]
From: |
Stefan Monnier |
Subject: |
Re: Alternate design [Was: Re: [RFC] some reworking of struct window] |
Date: |
Fri, 22 Mar 2013 09:34:27 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
>> 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
- Re: [RFC] some reworking of struct window, (continued)
Re: [RFC] some reworking of struct window, Dmitry Antipov, 2013/03/22