From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Alternate design [Was: Re: [RFC] some reworking of struct window] Date: Fri, 22 Mar 2013 09:34:27 -0400 Message-ID: References: <514AD54F.8050309@yandex.ru> <83620kzk8z.fsf@gnu.org> <514C0B07.3020307@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1363959306 12881 80.91.229.3 (22 Mar 2013 13:35:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Mar 2013 13:35:06 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 22 14:35:31 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UJ27z-0003h0-27 for ged-emacs-devel@m.gmane.org; Fri, 22 Mar 2013 14:35:27 +0100 Original-Received: from localhost ([::1]:54618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJ27b-00027D-63 for ged-emacs-devel@m.gmane.org; Fri, 22 Mar 2013 09:35:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJ27F-0001lA-DN for emacs-devel@gnu.org; Fri, 22 Mar 2013 09:34:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJ278-0006gI-VK for emacs-devel@gnu.org; Fri, 22 Mar 2013 09:34:41 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:17331) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJ272-0006fE-GR; Fri, 22 Mar 2013 09:34:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxKvA/2dsb2JhbABEvw4Xc4IeAQEEAScvIxALDiYSFBgNJIgeBsEtkQoDpHqBXoMT X-IPAS-Result: Av4EABK/CFFFxKvA/2dsb2JhbABEvw4Xc4IeAQEEAScvIxALDiYSFBgNJIgeBsEtkQoDpHqBXoMT X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="5532097" Original-Received: from 69-196-171-192.dsl.teksavvy.com (HELO pastel.home) ([69.196.171.192]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 22 Mar 2013 09:34:25 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 20B4D67AAC; Fri, 22 Mar 2013 09:34:27 -0400 (EDT) In-Reply-To: <514C0B07.3020307@yandex.ru> (Dmitry Antipov's message of "Fri, 22 Mar 2013 11:40:55 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:158061 Archived-At: >> 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