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 00:26:45 -0800 Message-ID: <4EFD75C5.7050405@dancol.org> References: <4b98eec4a5f68bfcd9233d5e7444de05873225b4.1325166472.git.dancol@dancol.org> <4EFCE9C4.8050908@dancol.org> <838vluv59t.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="------------enig1510006D3794BC7D70C80FB6" X-Trace: dough.gmane.org 1325233637 32146 80.91.229.12 (30 Dec 2011 08:27:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2011 08:27:17 +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 09:27:09 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 1RgXnw-0003qR-N7 for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 09:27:08 +0100 Original-Received: from localhost ([::1]:40783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgXnw-0006Jw-4f for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 03:27:08 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:43807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgXnt-0006Jr-VI for emacs-devel@gnu.org; Fri, 30 Dec 2011 03:27:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgXns-00048g-O4 for emacs-devel@gnu.org; Fri, 30 Dec 2011 03:27:05 -0500 Original-Received: from dancol.org ([96.126.100.184]:35741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgXnn-00047r-Ro; Fri, 30 Dec 2011 03:27:00 -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 1RgXnm-0001OR-PQ; Fri, 30 Dec 2011 00:26:58 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <838vluv59t.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:147032 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1510006D3794BC7D70C80FB6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/30/11 12:21 AM, Eli Zaretskii wrote: >> Date: Thu, 29 Dec 2011 14:29:24 -0800 >> From: Daniel Colascione >> Cc: emacs-devel@gnu.org >> >> My initial revisions actually did exactly what you suggest, but I >> realized that the solution was more complex and didn't actually have >> any benefit. >=20 > Can you describe the complexity in this solution? configure already knows what window system we're using, so it can set a macro to the name of the correct header without further logic. Nobody else has to be aware of the set of possible window systems. 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. >>> Also "TERM" does not look like a good prefix >>> in this case, it's meaning might be confused with the TERM environmen= t >>> variable (nsterm/w32term/xterm are not that great either, but better = not >>> propagate the confusion). >> >> "Term", I think, it pretty clear in the context of Emacs. Using a >> different name for the header constant wouldn't change the names of al= l >> the datatypes in that header. It's better to at least be consistently >> confusing. >> >> There's XTERM_HEADER, but this name has other issues. >=20 > How about WINSYS_HEADER? That's fine. --------------enig1510006D3794BC7D70C80FB6 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 iEYEARECAAYFAk79dccACgkQ17c2LVA10VscIACgnHuRUA1THopd+y9OVEgwKyj2 jyoAn27sDs82bURin+nK92ys6odTG0XR =n3NK -----END PGP SIGNATURE----- --------------enig1510006D3794BC7D70C80FB6--