From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] system-type cygwin with window-system w32 Date: Mon, 18 Jul 2011 19:29:20 +0300 Message-ID: <83r55n7dsv.fsf@gnu.org> References: <4E2377E2.1020804@gmail.com> <4E240C17.4020102@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1311011052 9779 80.91.229.12 (18 Jul 2011 17:44:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 17:44:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 18 19:44:08 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QirrU-0004Fc-0Q for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 19:44:08 +0200 Original-Received: from localhost ([::1]:43977 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QirrS-0002oT-Rm for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 13:44:07 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qiqhx-0007Wo-T3 for emacs-devel@gnu.org; Mon, 18 Jul 2011 12:30:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qiqht-00083H-9B for emacs-devel@gnu.org; Mon, 18 Jul 2011 12:30:13 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:48608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qiqhs-00082S-LA for emacs-devel@gnu.org; Mon, 18 Jul 2011 12:30:08 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LOJ00I00F4G6500@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 18 Jul 2011 19:29:23 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.133.66]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LOJ00HZQF4UC6C0@a-mtaout22.012.net.il>; Mon, 18 Jul 2011 19:29:19 +0300 (IDT) In-reply-to: <4E240C17.4020102@gmail.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142122 Archived-At: > 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. > >> + 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 ") ? > 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.