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 3/4] Implement cygw32 Date: Thu, 29 Dec 2011 13:50:32 -0800 Message-ID: <4EFCE0A8.1080305@dancol.org> References: <5624badc7ef2eea96f90da1a823144757a5f0290.1325166472.git.dancol@dancol.org> <83oburuvzt.fsf@gnu.org> <4EFCA8FF.5080200@dancol.org> <83fwg3uts8.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="------------enig9159315C89F3DCFE2052DE67" X-Trace: dough.gmane.org 1325195455 28002 80.91.229.12 (29 Dec 2011 21:50:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 29 Dec 2011 21:50:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 29 22:50:50 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 1RgNs9-00019n-VT for ged-emacs-devel@m.gmane.org; Thu, 29 Dec 2011 22:50:50 +0100 Original-Received: from localhost ([::1]:39898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgNs8-0007gS-Uh for ged-emacs-devel@m.gmane.org; Thu, 29 Dec 2011 16:50:48 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgNs4-0007gN-RS for emacs-devel@gnu.org; Thu, 29 Dec 2011 16:50:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgNs3-0007PU-E7 for emacs-devel@gnu.org; Thu, 29 Dec 2011 16:50:44 -0500 Original-Received: from dancol.org ([96.126.100.184]:34612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgNs1-0007PE-CK; Thu, 29 Dec 2011 16:50:41 -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 1RgNs0-0008Jg-5i; Thu, 29 Dec 2011 13:50:40 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <83fwg3uts8.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:147015 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9159315C89F3DCFE2052DE67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/29/11 10:17 AM, Eli Zaretskii wrote: >> Date: Thu, 29 Dec 2011 09:53:03 -0800 >> From: Daniel Colascione >> CC: emacs-devel@gnu.org >> >>>> --- a/lisp/faces.el >>>> +++ b/lisp/faces.el >>>> @@ -89,7 +89,7 @@ ALTERNATIVE2 etc." >>>> ;; This is defined originally in xfaces.c. >>>> (defcustom face-font-registry-alternatives >>>> (mapcar (lambda (arg) (mapcar 'purecopy arg)) >>>> - (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? >=20 > 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.) 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. >>>> --- a/lisp/frame.el >>>> +++ b/lisp/frame.el >>>> @@ -522,7 +522,7 @@ The optional argument PARAMETERS specifies addit= ional frame parameters." >>>> (ns-initialize-window-system)) >>>> (make-frame `((window-system . ns) >>>> (display . ,display) . ,parameters))) >>>> - ((eq system-type 'windows-nt) >>>> + ((eq window-system 'w32) >>>> ;; On Windows, ignore DISPLAY. >>>> (make-frame parameters)) >>>> (t >>> >>> Why not window-system the function? You do want to continue >>> supporting multi-tty in this configuration, right? >> >> I've tested multi-tty and it works fine. >=20 > Including X and w32 frames (on the same display)? I haven't tested an X11 and a cygw32 emacs running different servers at the same time, but I see no reason that this situation would be any different from two X11 emacs instances both running servers. >=20 >> When Emacs is configured with system-type cygwin and window-system >> w32, it still provides w32-ansi-code-page. >=20 > What for? In cygw32 mode, we try to provide as much of the win32 infrastructure as conveniently possible because doing so lets the user integrate her emacs with Windows as tightly as possible. (That's the point of using cygw32 over X11.) For example, she might want to write out a text file encoded in the system code page, then tell a native, non-Cygwin program about it. Leaving w32-ansi-code-page in the build does no harm provided we fix emacs so it isn't confused by the variable's presence. >>>> -(if (eq system-type 'windows-nt) >>>> +(if (or (eq system-type 'windows-nt) >>>> + (featurep 'w32)) >>>> (progn >>>> - (load "w32-vars") >>>> (load "term/common-win") >>>> + (load "w32-vars") >>> >>> Did you really need this order change? If yes, why? If not, I'd =2E.. >> No, moving w32-vars back on top shouldn't cause a problem. It really >> doesn't belong there though: shouldn't we load the more general code >> first, then let the platform-specific code muck with it? =2E.. > Maybe so, but I don't think it's worth time and energy to "fix" this. > The risk breaking something in subtle ways is very real, OTOH. =2E.. >> I can play with the order a bit, but to avoid code duplication, I'd >> strongly prefer to maintain the separation of the code in w32-common-f= ns >> and w32-fns. =2E.. > That's okay, and so is ls-lisp move (because it's largely independent > of the windowing stuff). But please keep the order of dos-w32 and > w32-fns. All right. It's the same to me, though the idea of the code being so delicate is troubling from a maintainability perspective. >>> You mean, the Cygwin build that uses w32 windowing will be unable to >>> support X selections? That would be a pity. >> >> Why would it? Emacs in this configuration is a native Windows >> application and it doesn't know a thing about X selections. >=20 > But there could be X frames in the same session, couldn't there be? > And if so, the X selection code is present, right? A cygw32 emacs could run in the same Windows session as an X server, to which a different, appropriately-configured copy of emacs could connect. But a single emacs instance can't even be compiled with both w32 and X11 windowing systems. I don't think such a build would be prohibitively difficult to implement (it's just a matter of adding a few levels of indirection), but it's outside the scope of this patch series. A cygw32 copy of emacs can no more talk X than a Mac or a DOS emacs can. >>>> +(defun w32-handle-dropped-file (window file-name) >>>> + (let ((f (if (eq system-type 'cygwin) >>>> + (cygwin-convert-path-from-windows file-name t) >>>> + (subst-char-in-string ?\\ ?/ file-name))) >>>> + (coding (or file-name-coding-system >>>> + default-file-name-coding-system))) >>> >>> What is the default value of default-file-name-coding-system in the >>> Cygwin build? There could be a conflict here between e.g. UTF-8 in >>> Cygwin and the Windows codepage. >> >> In Cygwin, default-file-name-coding-system will almost always be >> utf-8-unix because the default system locale is UTF-8. >> >> This particular function is a bit hairy, however: FILE-NAME is _alread= y_ >> decoded. The only reason we're mucking with the coding system here is= >> that dnd-handle-one-url unconditionally decodes its argument using (or= >> file-name-coding-system default-file-name-coding-system), so we have t= o >> re-encode what we give it. >=20 > But you will be encoding it with UTF-8, which the w32 windows cannot > grok at all. Or am I missing something? Windows never sees the encoded string here. At the end of it all, emacs encoded, and emacs hath decoded away. >>> Btw, will the above code be used by the Cygwin build? Does that >>> include default-printer-name etc.? >> >> The battery status functionality works fine under the Cygwin build, as= >> does default-printer-name. (I haven't tried to actually print anything= =2E) >=20 > Doesn't the Cygwin Emacs use lpr or some such to print? If so, the > name of the system printer will be useless for a Cygwin user, no? Cygwin can use Windows printer names (provided the slashes are converted appropriately). --------------enig9159315C89F3DCFE2052DE67 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 iEYEARECAAYFAk784KkACgkQ17c2LVA10VuH4wCfUCrdREdyDkCAXIeL5pTJ8wdR SVYAoMR9A8K0y3iVlBDXviqW+DxrRk6h =A/qa -----END PGP SIGNATURE----- --------------enig9159315C89F3DCFE2052DE67--