From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Colascione <dancol@dancol.org>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH 3/4] Implement cygw32
Date: Thu, 29 Dec 2011 20:17:27 +0200 [thread overview]
Message-ID: <83fwg3uts8.fsf@gnu.org> (raw)
In-Reply-To: <4EFCA8FF.5080200@dancol.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?
next prev parent reply other threads:[~2011-12-29 18:17 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-29 14:03 [PATCH 0/4] Support Win32 GUI in Cygwin Emacs Daniel Colascione
2011-12-29 14:03 ` [PATCH 1/4] Compilation cleanups Daniel Colascione
2011-12-29 17:54 ` Paul Eggert
2011-12-31 14:50 ` Ken Brown
2011-12-31 20:29 ` Paul Eggert
2011-12-29 14:03 ` [PATCH 2/4] Refactor window-system configuration Daniel Colascione
2011-12-29 22:21 ` Dan Nicolaescu
2011-12-29 22:29 ` Daniel Colascione
2011-12-29 22:43 ` Dan Nicolaescu
2011-12-29 22:48 ` Daniel Colascione
2011-12-29 23:05 ` Dan Nicolaescu
2011-12-29 23:08 ` Daniel Colascione
2011-12-30 8:54 ` Eli Zaretskii
2011-12-30 9:07 ` Daniel Colascione
2011-12-30 9:44 ` Eli Zaretskii
2011-12-30 0:53 ` Stefan Monnier
2011-12-30 8:21 ` Eli Zaretskii
2011-12-30 8:26 ` Daniel Colascione
2011-12-30 9:38 ` Eli Zaretskii
2011-12-30 9:45 ` Daniel Colascione
2011-12-30 11:15 ` Stefan Monnier
2011-12-30 8:19 ` Eli Zaretskii
2011-12-29 14:03 ` [PATCH 4/4] Fix emacsclient to work with cygw32 Daniel Colascione
2011-12-29 16:28 ` Juanma Barranquero
2011-12-29 16:36 ` Daniel Colascione
2011-12-29 16:43 ` Juanma Barranquero
2011-12-29 16:47 ` Daniel Colascione
2011-12-29 16:49 ` Juanma Barranquero
2011-12-29 17:39 ` Eli Zaretskii
2011-12-29 17:56 ` Daniel Colascione
2011-12-29 18:18 ` Eli Zaretskii
2011-12-29 18:53 ` Juanma Barranquero
2011-12-29 14:03 ` [PATCH 3/4] Implement cygw32 Daniel Colascione
2011-12-29 17:29 ` Eli Zaretskii
2011-12-29 17:53 ` Daniel Colascione
2011-12-29 18:17 ` Eli Zaretskii [this message]
2011-12-29 21:50 ` Daniel Colascione
2011-12-30 0:56 ` Jason Rumney
2011-12-30 9:23 ` Eli Zaretskii
2011-12-30 9:36 ` Daniel Colascione
2011-12-30 11:16 ` Eli Zaretskii
2011-12-30 9:49 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83fwg3uts8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dancol@dancol.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.