On 7/18/11 9:29 AM, Eli Zaretskii wrote: >> Date: Mon, 18 Jul 2011 03:33:59 -0700 >> From: Daniel Colascione >> CC: emacs-devel@gnu.org >> >>>> - if (!hprevinst) >>>> - { >>>> - w32_init_class (hinst); >>>> - } >>>> + w32_init_class (hinst); >>> >>> Not sure why the test was deleted here. Can you explain? >> >> hprevinst isn't trivially available under Cygwin, and I don't see what >> the test is buying us: class registration is inexpensive. > > But then for Cygwin the condition will always be false, and the net > effect is to always call the function, as you wanted, right? So I > would rather we left the code alone. We'd still need the variable with your proposal, and I don't see what the existing behavior has, even in the NT case. >>>> + htext = GlobalAlloc (GMEM_MOVEABLE | GMEM_DDESHARE, bytes); >>>> + if (!htext) >>>> + error ("GlobalAlloc: %s", w32_strerror (GetLastError ())); >>> >>> Such cryptic error messages are not useful, because users are not >>> required to know what GlobalAlloc is. Please modify the text to be >>> more palatable to mere mortals (here and elsewhere in this part of the >>> patch). >> >> Well, it's better than what we used to do much of the time, which was to >> not check error codes at all. How would you suggest changing the >> messages? > > How about calling memory_full? > > Or maybe error ("Not enough memory ") ? The error isn't necessarily fatal --- and in general (speaking to other instances of w32_strerror in the patch) we don't always know what exactly went wrong. It'd be nice to give users an opportunity to figure it out. Maybe we can recognize a subset of error codes and forward those to memory_full. >> We could just the UI thread for this purpose instead of a dedicated one, > > This is what I had in mind as the alternative, yes. > >> What if I want to create a GUI-less Emacs that can nevertheless >> can interact with the system clipboard? > > GUI-less Emacs normally doesn't interact with the clipboard, so > there's no need to choose a design that complicates things just > because we would like to make this feature available on a single > platform. The complexity has to be present regardless. > Anyway, I'm hardly an expert on this particular issue (i.e. Windows > GUI and the message pump). I'm just worried by the fact that we will > have 2 threads calling GetMessage; in my experience this could lead to > hard-to-debug problems. Calling GetMessage in two threads is very common and well-supported, and won't by itself cause problems. If anything, separating the message loops makes the program more robust --- each message loop is less complex and thereby easier to understand.