emacs-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] system-type cygwin with window-system w32


From: Eli Zaretskii
Subject: Re: [PATCH] system-type cygwin with window-system w32
Date: Mon, 18 Jul 2011 19:29:20 +0300

> Date: Mon, 18 Jul 2011 03:33:59 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
> 
> >> -  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.

> >> +  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 <TO DO WHATEVER THIS CODE DOES>") ?

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

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.



reply via email to

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