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: [PATCH 2/4] Refactor window-system configuration Date: Thu, 29 Dec 2011 19:53:52 -0500 Message-ID: References: <4b98eec4a5f68bfcd9233d5e7444de05873225b4.1325166472.git.dancol@dancol.org> <4EFCE9C4.8050908@dancol.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325242512 18143 80.91.229.12 (30 Dec 2011 10:55:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2011 10:55:12 +0000 (UTC) Cc: Dan Nicolaescu , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 30 11:55:07 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 1Rga79-0004VI-Dp for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 11:55:07 +0100 Original-Received: from localhost ([::1]:54856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rga78-0000RR-Hq for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 05:55:06 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:43700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rga75-0000Qi-Rz for emacs-devel@gnu.org; Fri, 30 Dec 2011 05:55:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rga74-00044J-Q6 for emacs-devel@gnu.org; Fri, 30 Dec 2011 05:55:03 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:40614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rga74-00043s-NM; Fri, 30 Dec 2011 05:55:02 -0500 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id pBUAsrK0026457; Fri, 30 Dec 2011 05:54:55 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 303CC66289; Thu, 29 Dec 2011 19:53:52 -0500 (EST) In-Reply-To: <4EFCE9C4.8050908@dancol.org> (Daniel Colascione's message of "Thu, 29 Dec 2011 14:29:24 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4086=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4086> : streams <715113> : uri <1037433> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:147046 Archived-At: >> We don't use something like "#include TERM_HEADER" in any other place, >> it you really want to consolidate this stuff, creating a new header >> file to include seems better. > There's a first time for everything, and besides: other projects have > successfully used this approach. 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. > Besides, we have src/s/*.h and src/m/*.h. At least this approach is > explicit. I guess "#include TERM_HEADER" is OK for "now" (i.e. for when the trunk gets unfrozen). >> Also "TERM" does not look like a good prefix >> in this case, it's meaning might be confused with the TERM environment >> 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 all > the datatypes in that header. It's better to at least be consistently > confusing. > There's XTERM_HEADER, but this name has other issues. We need to create a new file where we can put the common code shared between the various *term.c files. Not sure how we could/should call this file, but it could be "guiterm.c", in which case GUITERM_HEADER might make sense as well. Stefan