[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Antipov
Subject: Re: Alternate design [Was: Re: [RFC] some reworking of struct window]
Date: Mon, 25 Mar 2013 19:29:48 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

On 03/22/2013 05:34 PM, Stefan Monnier wrote:

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").

OK, what about neutral `contained'?

+    /* 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.

Yes; this makes the 'previous' (before nil was assigned to W->payload) state
undefined, but it shouldn't be a problem.

+  ((W)->combination && (W)->horizontal)

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

This will require a lot of explicit checking whether W->payload is a window,
for example in Fwindow_top_child and Fwindow_left_child. I believe that we
should treat dead windows as 'typeless' (that is, all of WINDOW_LEAF_P and
WINDOW_xxx_COMBINATION_P should return false for them) and add explicit
eassert where leaf or dead window can cause serious problems.


Attachment: window_contained.patch
Description: Text document

reply via email to

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