From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 2/4] Refactor window-system configuration Date: Fri, 30 Dec 2011 01:45:36 -0800 Message-ID: <4EFD8840.4040107@dancol.org> References: <4b98eec4a5f68bfcd9233d5e7444de05873225b4.1325166472.git.dancol@dancol.org> <4EFCE9C4.8050908@dancol.org> <838vluv59t.fsf@gnu.org> <4EFD75C5.7050405@dancol.org> <83vcoytn4y.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A6FEF9FD1A28736DE574080" X-Trace: dough.gmane.org 1325238353 25753 80.91.229.12 (30 Dec 2011 09:45:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2011 09:45:53 +0000 (UTC) Cc: dann@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 30 10:45:48 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RgZ23-0002vU-Mn for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 10:45:47 +0100 Original-Received: from localhost ([::1]:46008 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgZ23-00037a-6e for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 04:45:47 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgZ20-00037H-2I for emacs-devel@gnu.org; Fri, 30 Dec 2011 04:45:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgZ1y-0000D1-UE for emacs-devel@gnu.org; Fri, 30 Dec 2011 04:45:44 -0500 Original-Received: from dancol.org ([96.126.100.184]:35901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgZ1v-0000Ch-Pi; Fri, 30 Dec 2011 04:45:39 -0500 Original-Received: from c-24-18-179-193.hsd1.wa.comcast.net ([24.18.179.193] helo=[192.168.1.2]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RgZ1v-0001Yi-7j; Fri, 30 Dec 2011 01:45:39 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <83vcoytn4y.fsf@gnu.org> X-Enigmail-Version: 1.3.4 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 96.126.100.184 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:147044 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A6FEF9FD1A28736DE574080 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/30/11 1:38 AM, Eli Zaretskii wrote: >> Date: Fri, 30 Dec 2011 00:26:45 -0800 >> From: Daniel Colascione >> On the other hand, using a fixed "dispatch header" --- i.e., one that >> contains a bunch of preprocessor branches and include directives --- >> forces us to create yet another place that has to know about all >> possible window systems. >=20 > I see nothing particularly complex about this, FWIW.=20 The header decision tree would be more logic that doesn't have to be there. It would amount to yet another moving part in the configuration machine. Sure, putting this decision tree in one place is better than pasting it into every C file that does something with a frame (the current approach), but getting rid of it altogether would be even better.= I honestly don't understand why you're opposed to the include-a-macro approach, or what you find unclear about it. > We have our > share of such ifdefs already And we should try to centralize these things and make sure we have as few as possible. They make code hard to follow, especially when nested. --------------enig4A6FEF9FD1A28736DE574080 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk79iEEACgkQ17c2LVA10Vs+rgCgqbI4CXo3ek2mROMX1SDg2dCV yqsAoKLLCMJDinT1SjgPHft/SdJtL8ZQ =YZz7 -----END PGP SIGNATURE----- --------------enig4A6FEF9FD1A28736DE574080--