[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/4] Implement cygw32
From: |
Eli Zaretskii |
Subject: |
Re: [PATCH 3/4] Implement cygw32 |
Date: |
Thu, 29 Dec 2011 20:17:27 +0200 |
> Date: Thu, 29 Dec 2011 09:53:03 -0800
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
>
> >> --- 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?
- Re: [PATCH 2/4] Refactor window-system configuration, (continued)
- Re: [PATCH 2/4] Refactor window-system configuration, Eli Zaretskii, 2011/12/30
- Re: [PATCH 2/4] Refactor window-system configuration, Daniel Colascione, 2011/12/30
- Re: [PATCH 2/4] Refactor window-system configuration, Eli Zaretskii, 2011/12/30
- Re: [PATCH 2/4] Refactor window-system configuration, Daniel Colascione, 2011/12/30
- Re: [PATCH 2/4] Refactor window-system configuration, Stefan Monnier, 2011/12/31
- Re: [PATCH 2/4] Refactor window-system configuration, Stefan Monnier, 2011/12/30
- Re: [PATCH 2/4] Refactor window-system configuration, Eli Zaretskii, 2011/12/30
[PATCH 3/4] Implement cygw32, Daniel Colascione, 2011/12/29
- Re: [PATCH 3/4] Implement cygw32, Eli Zaretskii, 2011/12/29
- Re: [PATCH 3/4] Implement cygw32, Daniel Colascione, 2011/12/29
- Re: [PATCH 3/4] Implement cygw32,
Eli Zaretskii <=
- Re: [PATCH 3/4] Implement cygw32, Daniel Colascione, 2011/12/29
- Re: [PATCH 3/4] Implement cygw32, Jason Rumney, 2011/12/29
- Re: [PATCH 3/4] Implement cygw32, Eli Zaretskii, 2011/12/30
- Re: [PATCH 3/4] Implement cygw32, Daniel Colascione, 2011/12/30
- Re: [PATCH 3/4] Implement cygw32, Eli Zaretskii, 2011/12/30
Re: [PATCH 3/4] Implement cygw32, Andreas Schwab, 2011/12/30