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: Thu, 29 Dec 2011 20:17:27 +0200 Message-ID: <83fwg3uts8.fsf@gnu.org> References: <5624badc7ef2eea96f90da1a823144757a5f0290.1325166472.git.dancol@dancol.org> <83oburuvzt.fsf@gnu.org> <4EFCA8FF.5080200@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325182659 11332 80.91.229.12 (29 Dec 2011 18:17:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 29 Dec 2011 18:17:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 29 19:17:34 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 1RgKXl-0002BS-RT for ged-emacs-devel@m.gmane.org; Thu, 29 Dec 2011 19:17:34 +0100 Original-Received: from localhost ([::1]:45981 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgKXl-000297-80 for ged-emacs-devel@m.gmane.org; Thu, 29 Dec 2011 13:17:33 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgKXi-000292-2p for emacs-devel@gnu.org; Thu, 29 Dec 2011 13:17:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgKXg-0005uz-Nv for emacs-devel@gnu.org; Thu, 29 Dec 2011 13:17:30 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:64930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgKXg-0005un-BF for emacs-devel@gnu.org; Thu, 29 Dec 2011 13:17:28 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LWZ00H00979LB00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Thu, 29 Dec 2011 20:17:27 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.18.76]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LWZ00HLS9H2KI30@a-mtaout23.012.net.il>; Thu, 29 Dec 2011 20:17:27 +0200 (IST) In-reply-to: <4EFCA8FF.5080200@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.175 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:147009 Archived-At: > 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? A defcustom is evaluated more than once. So I'm a bit fuzzy about "too early" ;-) > >> --- a/lisp/frame.el > >> +++ b/lisp/frame.el > >> @@ -522,7 +522,7 @@ The optional argument PARAMETERS specifies additional 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. Including X and w32 frames (on the same display)? > When Emacs is configured with system-type cygwin and window-system > w32, it still provides w32-ansi-code-page. What for? > >> --- a/lisp/loadup.el > >> +++ b/lisp/loadup.el > >> @@ -207,15 +207,18 @@ > >> (load "term/common-win") > >> (load "term/x-win"))) > >> > >> -(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 > > prefer to leave the original order, as changing it could potentially > > cause unintended consequences. > > 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? 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. > >> (load "term/w32-win") > >> - (load "ls-lisp") > >> (load "disp-table") > >> - (load "dos-w32") > >> - (load "w32-fns"))) > >> + (load "w32-common-fns") > >> + (when (eq system-type 'windows-nt) > >> + (load "w32-fns") > >> + (load "ls-lisp") > >> + (load "dos-w32")))) > > > > Likewise here: at the very least, keep the order in the group of > > packages loaded for windows-nt. > > 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-fns > and w32-fns. 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. > > 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. But there could be X frames in the same session, couldn't there be? And if so, the X selection code is present, right? > >> +(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 _already_ > 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 to > re-encode what we give it. But you will be encoding it with UTF-8, which the w32 windows cannot grok at all. Or am I missing something? > > 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.) 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?