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: Sun, 17 Jul 2011 23:29:19 -0700 Message-ID: <4E23D2BF.7080309@gmail.com> References: <4E2377E2.1020804@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAE4D585B19BB85080FBC4D65" X-Trace: dough.gmane.org 1310970597 20028 80.91.229.12 (18 Jul 2011 06:29:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 06:29:57 +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 08:29:51 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 1QihKw-0003sT-L5 for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 08:29:50 +0200 Original-Received: from localhost ([::1]:45461 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QihKv-0007rJ-IY for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 02:29:49 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QihKd-0007r8-18 for emacs-devel@gnu.org; Mon, 18 Jul 2011 02:29:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QihKb-0004K3-Tj for emacs-devel@gnu.org; Mon, 18 Jul 2011 02:29:30 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:40023) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QihKa-0004Jh-6H; Mon, 18 Jul 2011 02:29:28 -0400 Original-Received: by iyb14 with SMTP id 14so1755408iyb.0 for ; Sun, 17 Jul 2011 23:29:27 -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=QYAMFSLoUrChpzDEuSPgxW5yBwvdO59lYpx88H5Q73E=; b=SNGdCz2uMMpcrtOMamRGifbfGDI2ZXqsNt8FZpPr3cfC0OjHTAx5s2Yv6G4PqPpRQ7 1JD+/zl5hJGfScx7oGIy6E7mN8B7RhyOJprXaWeFd+fC5Ktnu1kus9u5tTbVNc0QSe7E AeA2X7PEFmAb2UH1UNcpAZ96tTz9FT+gfBZJU= Original-Received: by 10.42.167.72 with SMTP id r8mr2337921icy.131.1310970567428; Sun, 17 Jul 2011 23:29:27 -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 hq1sm4558203icc.2.2011.07.17.23.29.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jul 2011 23:29:26 -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: 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:142087 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAE4D585B19BB85080FBC4D65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Eli, Thanks for reviewing the patch. On 7/17/11 11:13 PM, Eli Zaretskii wrote: > Why did you need to change filemode.c? Does it have anything to do > with Cygwin on w32? S_ISCTG and such aren't being defined under Cygwin, causing compilation errors. There's probably a better way to deal with the underlying proble= m. > What is this (and related) stuff about? Why do you need to use HTML > wrt the clipboard? Windows uses HTML as a data interchange format --- supporting it as a clipboard format allows formatting to be preserved in pastes into other programs. This code could easily be structured as a separate package, however, and I'll end up doing that. See http://msdn.microsoft.com/en-us/library/ms649015%28v=3Dvs.85%29.aspx >> -/* Equivalent of strerror for W32 error codes. */ >> -char * >> -w32_strerror (int error_no) >> -{ >> - static char buf[500]; > > I don't like the idea of moving this to w32fns.c, because it doesn't > belong there. Can you come up with an alternative idea? The fundamental problem is that we now have two Windows platforms: WINDOWSNT and (CYGWIN && HAVE_NTGUI). The common code has to live somewhere; with my patch, we only build w32.o in the NTEMACS case because w32.c contains mostly compatibility wrappers; the non-compatibility portions I moved to w32fns.c, which we compile in both cases. Cygwin-NT-specific code goes in the new file cygw32.c. Another option would be to further refactor the Win32 code into distinct and explicit WINDOWSNT and HAVE_NTGUI files and introduce common headers for common functionality. This approach would involve even more code movement, however, which is why I initially avoided it. >> +#define t(...) \ >> + ({ \ >> + fprintf (stderr, "T:%s:%u: ", \ >> + __FUNCTION__, __LINE__); \ >> + fprintf (stderr, __VA_ARGS__); \ >> + fputc ('\n', stderr); \ >> + }) >> + >=20 > What is this stuff about? Debug scaffolding --- in this case, generally useful, I think, at least as a replacement for the numerous bespoke tracing macros scattered everywhere in the code. >=20 >> -/* Equivalent of strerror for W32 error codes. */ >> -char * >> -w32_strerror (int error_no) >> -{ >> - static char buf[500]; >=20 > I don't like the idea of moving this to w32fns.c, because it doesn't > belong there. Can you come up with an alternative idea? >=20 >> +#if EMACSDEBUG >> +const char* >> +w32_name_of_message (UINT msg) >=20 > Why is this needed? Debug scaffolding. >> + =20 >> + /* DebPrint (("w32_msg_pump: %s time:%u\n", */ >> + /* w32_name_of_message (msg.message), msg.time)); */= >> + =20 >=20 > Can this be removed? These DebPrint messages are a PITA when > debugging, so if it isn't absolutely necessary, let's not add new > ones. Sure. I'd actually prefer, though, to leave the existing tracing, but move it all to a common macro so that the debug spam is easier to disable and enable as needed. >=20 > This is based on reviewing only a part of the patch, I will have more > later. The patch is very large and complicated, and the lack of a > ChangeLog that describes the changes, particularly those which move > code between different files, does not help... Of course. It's a work in progress --- a first stab, really. Once I clean up the code a bit, I'll put it into a form that's easier to consume= =2E --------------enigAE4D585B19BB85080FBC4D65 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) iEYEARECAAYFAk4j0sMACgkQ17c2LVA10VsT9wCfbf/6UvMe+0Xc3Pf3Tqk1WJaM wKAAn1rWOIt1HE3VtKmXgDKdLEkWUf1e =AcuY -----END PGP SIGNATURE----- --------------enigAE4D585B19BB85080FBC4D65--