From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 3/4] Implement cygw32 Date: Fri, 30 Dec 2011 11:23:47 +0200 Message-ID: <83zkeatnto.fsf@gnu.org> References: <5624badc7ef2eea96f90da1a823144757a5f0290.1325166472.git.dancol@dancol.org> <83oburuvzt.fsf@gnu.org> <4EFCA8FF.5080200@dancol.org> <83fwg3uts8.fsf@gnu.org> <4EFCE0A8.1080305@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325237036 18408 80.91.229.12 (30 Dec 2011 09:23:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2011 09:23:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 30 10:23:53 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 1RgYgq-0003Zx-MQ for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 10:23:52 +0100 Original-Received: from localhost ([::1]:48764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgYgq-0007Qe-6y for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 04:23:52 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:42686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgYgo-0007QL-3n for emacs-devel@gnu.org; Fri, 30 Dec 2011 04:23:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgYgn-0005C2-4U for emacs-devel@gnu.org; Fri, 30 Dec 2011 04:23:50 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:62265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgYgm-0005Bw-Qg for emacs-devel@gnu.org; Fri, 30 Dec 2011 04:23:49 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LX000700FE94H00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 30 Dec 2011 11:23:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.18.76]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LX000MXBFFLLF23@a-mtaout22.012.net.il>; Fri, 30 Dec 2011 11:23:47 +0200 (IST) In-reply-to: <4EFCE0A8.1080305@dancol.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:147039 Archived-At: > Date: Thu, 29 Dec 2011 13:50:32 -0800 > From: Daniel Colascione > CC: emacs-devel@gnu.org > > >>>> - (if (eq system-type 'windows-nt) > >>>> + (if (featurep 'w32) > >>>> '(("iso8859-1" "ms-oemlatin") > >>>> ("gb2312.1980" "gb2312" "gbk" "gb18030") > >>>> ("jisx0208.1990" "jisx0208.1983" "jisx0208.1978") > >>> > >>> Why not use window-system (the function) here? > >> > >> Isn't it a little early for window-system at this point? > > > > A defcustom is evaluated more than once. So I'm a bit fuzzy about > > "too early" ;-) > > When we initialize for the first time, we won't have a GUI frame to > check, yes? (And then we dump the table into pure storage.) In a release tarball, this first time is normally on a GNU/Linux box, and so the w32-specific setting will never be chosen. The important initialization is when the dumped Emacs is started on a Windows system. At that time, we do have a GUI frame, I think. > If there's > no facility to force reevaluation of the mapping table, we'll end up > using the wrong one when we *do* finally come up with a GUI frame. But there _is_ such a facility: defcustoms are reevaluated upon startup (and then again when you actually use "M-x customize", or have custom-related forms in your .emacs). This must be so, because otherwise the values will inherit the platform where Emacs was dumped. Anyway, given what Jason wrote about this particular variable, it is not worth arguing about. My point, however, is that it is a good idea to use window-system (the function) where it could happen that different frames have different types, in the current mult-tty Emacs. If nothing else, using window-system consistently contributes to the clarity of the code and shows the overall design to newcomers, who would otherwise become confused if they see inconsistent tests in each and every place.