Re: [PATCH 3/4] Implement cygw32

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 29 Dec 2011 09:53:03 -0800
> From: Daniel Colascione <dancol@dancol.org>
> 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?