[Top][All Lists]
[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.
- Re: [PATCH] system-type cygwin with window-system w32, (continued)
- Re: [PATCH] system-type cygwin with window-system w32, Richard Stallman, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Daniel Colascione, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, David Kastrup, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Daniel Colascione, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Richard Stallman, 2011/07/19
- Re: [PATCH] system-type cygwin with window-system w32, Lennart Borgman, 2011/07/20
- Re: [PATCH] system-type cygwin with window-system w32, Jason Rumney, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Richard Riley, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, Eli Zaretskii, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, Stefan Monnier, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, Andreas Schwab, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, Stefan Monnier, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, grischka, 2011/07/18