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 03:49:41 -0700 Message-ID: <4E240FC5.3050509@gmail.com> References: <4E2377E2.1020804@gmail.com> <4E23DA4A.1080301@gmail.com> <4E23FFB4.1040809@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig48557B6E12BF02F5A7652BD7" X-Trace: dough.gmane.org 1310986404 12078 80.91.229.12 (18 Jul 2011 10:53:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 10:53:24 +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 12:53:20 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 1QilRv-00079w-SP for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 12:53:20 +0200 Original-Received: from localhost ([::1]:34027 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QilRu-0007U5-6Z for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 06:53:18 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42660) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QilOk-0006jb-In for emacs-devel@gnu.org; Mon, 18 Jul 2011 06:50:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QilOg-0000GV-3l for emacs-devel@gnu.org; Mon, 18 Jul 2011 06:50:02 -0400 Original-Received: from mail-iw0-f169.google.com ([209.85.214.169]:36625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QilOa-0000G9-CR; Mon, 18 Jul 2011 06:49:52 -0400 Original-Received: by iwn8 with SMTP id 8so3244657iwn.0 for ; Mon, 18 Jul 2011 03:49:51 -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=52ayhal9W0+YQYyEqacVl9OokJtwrgQ6o1fVZM/rakk=; b=r86DPyCs1w38utKA7tKdathFovkmHE7tiRztLK/cWfzCJ67v0LSVxdXu2UCUlBiDVx mS7J9GeGbkahB+yRH5ZnHxTtpoc100gY+Iyu15+iV7Q290DiSSuV7TWtIwx3MdltoVeT XcTmx02zIXqDgorIoA75hWHkbIjH+6virKpRQ= Original-Received: by 10.42.96.6 with SMTP id h6mr6801767icn.271.1310986191151; Mon, 18 Jul 2011 03:49:51 -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 h6sm4839823icy.1.2011.07.18.03.49.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jul 2011 03:49:50 -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.214.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:142099 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig48557B6E12BF02F5A7652BD7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/18/11 3:10 AM, Eli Zaretskii wrote: >> Date: Mon, 18 Jul 2011 02:41:08 -0700 >> From: Daniel Colascione >> CC: emacs-devel@gnu.org >> >> The 9X family is long dead. >=20 > Not in the 3rd world, where there are still many machines running it. > Or so we were told last time this issue popped up. RMS personally > asked not to drop W9X on this behalf. I don't recall that discussion. Can we reopen it? According to [1], Windows 98 has a market share of 0.03%. I suspect there are more VMS users, and we dropped support for that OS. Besides: shouldn't we be encouraging computationally indigent third world users to switch to use free operating systems instead? 9X users have no protection against security vulnerabilities. >> We shouldn't forgo technical improvement on the account of a dead >> system. >=20 > I didn't say we should stop the improvement. You will find quite a > few Emacs features that use APIs which are unavailable on W9X. But > they do it in a way that lets Emacs still run on W9X and produce > reasonable results, be that some fallback or just plain message saying > that this nifty feature is not available. (Of course, disabling menus > or file access cannot use the latter fire escape, because they are too > basic and without them Emacs would become unusable.) These fallbacks involve significant complexity, and they're lightly-tested at best. I'd prefer to eliminate the complexity involved in supporting these alleged 9X users by simply dropping the support. Moving to all-Unicode APIs would improve Emacs' internationalization support _and_ simplify the codebase. >>> and (2) going Unicode means that all the existing APIs >>> used by Emacs will have to be switched to Unicode.=20 >> >> Why not do it piecemeal? We can directly call Unicode APIs where >> appropriate. >=20 > I'm not sure I understand the details of your proposal. The situation > that worries me is this: >=20 > . user uses the file dialog to return a file name in UTF-16 which > includes characters not available in the system codepage (this is > quite possible on NTFS) >=20 > . the file name is passed to file-attributes or insert-file-name or > some other primitive that accepts file names It'd be straightforward to locate all calls to CreateFile and such and update them to use unicode APIs. Cygwin supports UTF-8 filenames nativel= y. But even if we don't --- why does it matter? You can create files using the NT native API that can't be opened using Win32 calls; it doesn't cause a problem in practice. Likewise, users who have strange filesnames might not be able to use them with all Emacs features right away, but they'll be able to work with more reasonable filenames just as they did before. > . if the underlying file APIs used by these primitives (`stat', > `open', `opendir', etc.) are not Unicode, these primitives will > fail in weird ways, like "file does not exist" etc., that would > just confuse the user. I'd prefer to go all-Unicode because I don't think unencodable filenames are common enough to warrant much concern here. Any file users can manipulate today, they'll be able to manipulate with a partially-Unicodeized Emacs. Still, if we can't do that, then as a temporary measure, we can still use Unicode APIs (the 9X discussion notwithstanding), but as a temporary measure, filter their results so that we reject filenames that can't be used with the system codepage. [1] http://marketshare.hitslink.com/operating-system-market-share.aspx?spider= =3D1&qprid=3D10&qpcal=3D1&qpcal=3D1&qptimeframe=3DM&qpsp=3D148 --------------enig48557B6E12BF02F5A7652BD7 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) iEYEARECAAYFAk4kD8oACgkQ17c2LVA10VuMnwCeJ7MjqWnHOzAhjc2peMnAqGcM micAoMCLsquhs3oY/y46YI8D4gQIwcQt =zJEk -----END PGP SIGNATURE----- --------------enig48557B6E12BF02F5A7652BD7--