emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Override Windows default Win-* key combinations when using E


From: Eli Zaretskii
Subject: Re: [PATCH] Override Windows default Win-* key combinations when using Emacs
Date: Mon, 29 Feb 2016 17:52:49 +0200

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sun, 28 Feb 2016 23:07:38 -0800
> 
> >> The Gnulib getaddrinfo module is supposed to work on MS-Windows. If Emacs 
> >> used
> >> >the Gnulib getaddrinfo module, the mainline Emacs code could be 
> >> >simplified by
> >> >assuming that getaddrinfo works.
> 
> > But the non-getaddrinfo parts are not conditioned on MS-Windows in any
> > way.  What about other systems that might be using them?
> 
> Sorry, you've lost me.  The non-getaddrinfo parts of Gnulib?  Of Emacs?

Of Emacs, of course.

> For what it's worth, the Gnulib getaddrinfo module is supposed to work on a 
> wide 
> variety of systems lacking getaddrinfo, not just on MS-Windows.

I was talking about systems other than Windows.  Do we know which ones
of them still use the non-getaddrinfo code?

I see that we have calls to something named res_init there, and we
even have a configure-time test for that.  What is that about?  Gnulib
doesn't have that, and it's certainly not for the MS-Windows build.

> I'm sure you mean something straightforward, it's just that I'm not getting 
> it.

Sorry for being unclear.

> What I was thinking was that we add the Gnulib getaddrinfo module, and apply 
> something like the attached (untested) patch.

Thanks.  I don't object to this, but I don't think we can use this on
Windows.  The current w32 code in Emacs wraps each network-related
function with a wrapper that tracks sockets and file descriptors they
use, translates socket errors to errno values, and does other
important stuff.  The code also arranges for dynamically loading the
socket library only when actually needed.  So replacing just one
function will certainly not work well, and replacing them all sounds
like a lot of work for very little gain.

So I think a better way forward would be to implement getaddrinfo
wrapper in w32.c, complete with the fallback we have in process.c (and
maybe also borrowing some ideas from Gnulib).  When this is done, we
can install your patch for whatever other systems which still don't
have getaddrinfo (if there are such systems that we still support).

Writing such a getaddrinfo wrapper is easy, and I expect it to be done
soon enough, so please wait with your patch until then.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]