From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] system-type cygwin with window-system w32 Date: Mon, 18 Jul 2011 10:04:31 -0700 Message-ID: <4E24679F.5080807@gmail.com> References: <4E2377E2.1020804@gmail.com> <4E240C17.4020102@gmail.com> <83r55n7dsv.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBDB412F5D4105842E733FFA1" X-Trace: dough.gmane.org 1311009169 29755 80.91.229.12 (18 Jul 2011 17:12:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 17:12:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 18 19:12:45 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 1QirN6-0007we-UT for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 19:12:45 +0200 Original-Received: from localhost ([::1]:49526 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QirN6-0002Zk-27 for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 13:12:44 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:35526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QirFT-0000PZ-Oy for emacs-devel@gnu.org; Mon, 18 Jul 2011 13:04:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QirFP-0004wj-LC for emacs-devel@gnu.org; Mon, 18 Jul 2011 13:04:51 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:41415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QirFI-0004v1-24; Mon, 18 Jul 2011 13:04:40 -0400 Original-Received: by iyb14 with SMTP id 14so2306184iyb.0 for ; Mon, 18 Jul 2011 10:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=iqvaj5WIfUa/Zwrl4a5fF4pmScH5XY9w0n7ipc0Dyvo=; b=A6RIMmwpibdwEC/EIfAr2qOvV8kszVDCvul37BJlvd4iVG9pd57NPRPUxeacU6QCJu etGVG35mbUDGsy15ZFUg85r4+MvpNKLJc/UWFZyWMS4QZ00ESdpkcOcnIZFCDWmYKqQ9 NYeOYkh7+PsNncpXu1Pn8ZU9xzcZFTldBIF2A= Original-Received: by 10.42.74.130 with SMTP id w2mr6952357icj.462.1311008678611; Mon, 18 Jul 2011 10:04:38 -0700 (PDT) Original-Received: from [192.168.1.2] (c-24-18-179-193.hsd1.wa.comcast.net [24.18.179.193]) by mx.google.com with ESMTPS id vj5sm5126230icb.11.2011.07.18.10.04.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jul 2011 10:04:37 -0700 (PDT) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <83r55n7dsv.fsf@gnu.org> X-Enigmail-Version: 1.2 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 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:142119 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBDB412F5D4105842E733FFA1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. >=20 > 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 =3D 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 th= e >>> 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? >=20 > How about calling memory_full? >=20 > 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 on= e, >=20 > This is what I had in mind as the alternative, yes. >=20 >> What if I want to create a GUI-less Emacs that can nevertheless >> can interact with the system clipboard? >=20 > 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. --------------enigBDB412F5D4105842E733FFA1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk4kZ6MACgkQ17c2LVA10VuOKwCcDd0NrFicsasD7BOyHaotU4WF 6ZsAoMOOp+z8D/QsbjyE2BkyYC2HTsrC =zald -----END PGP SIGNATURE----- --------------enigBDB412F5D4105842E733FFA1--