Re: [PATCH 3/4] Implement cygw32

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 6433 bytes --]

On 12/29/11 10:17 AM, Eli Zaretskii wrote:
>> 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" ;-)

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 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)?

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.

> 
>> When Emacs is configured with system-type cygwin and window-system
>> w32, it still provides w32-ansi-code-page.
> 
> 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
...
>> 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.
...
>> 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.

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.
> 
> 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 _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?

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.)
> 
> 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).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]