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:41:16 +0300 Message-ID: <83pql77d8z.fsf@gnu.org> References: <4E2377E2.1020804@gmail.com> <4E23DA4A.1080301@gmail.com> <4E23FFB4.1040809@gmail.com> <4E240FC5.3050509@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1311007473 18589 80.91.229.12 (18 Jul 2011 16:44:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 16:44:33 +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 18:44:29 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 1Qiqvg-0004Ws-Kg for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 18:44:24 +0200 Original-Received: from localhost ([::1]:45936 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qiqvf-00032y-DM for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 12:44:23 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qiqsl-0002Ke-4g for emacs-devel@gnu.org; Mon, 18 Jul 2011 12:41:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qiqsg-0001Bd-Id for emacs-devel@gnu.org; Mon, 18 Jul 2011 12:41:22 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:34548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qiqsg-0001BV-49 for emacs-devel@gnu.org; Mon, 18 Jul 2011 12:41:18 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LOJ00600FLTSO00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 18 Jul 2011 19:41:15 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.133.66]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LOJ005FVFOR8ZH0@a-mtaout20.012.net.il>; Mon, 18 Jul 2011 19:41:15 +0300 (IDT) In-reply-to: <4E240FC5.3050509@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.166 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:142115 Archived-At: > Date: Mon, 18 Jul 2011 03:49:41 -0700 > From: Daniel Colascione > CC: emacs-devel@gnu.org > > > 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? Let's wait for Richard to chime in. > > 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. I'd prefer that as well, as soon as we drop W9X support. > > . 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) > > > > . 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. I'm afraid it isn't straightforward. I suspect there's a lot of supporting code that still assumes unibyte characters. But I'll welcome patches in that area (if we agree to drop W9X support). > Cygwin supports UTF-8 filenames natively. I know that, but it isn't relevant to the native w32 build, because that needs to use UTF-16, not UTF-8. > 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. But switching to Unicode doesn't make sense _unless_ you want to support "strange file names": all the non-strange file names are already supported under the current ``ANSI'' APIs. It's when I want to see file names with characters not from my system locale that I need Unicode. > > . 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. Sorry, I disagree. I have quite a few on my system, for example. If you want to know how I got them, then they came with zip files that included dictionaries in all kinds of languages, I brought them in when I worked in a Windows port of Ispell. And that's just one example that came to my mind, I'm sure I would find more if I cared to look. E.g., I remember seeing file names with Kanji characters at some point. IMO, a half-broken feature is worse than an absent feature. Especially if the breakage reveals itself as subtly as "file does not exist" when I just selected it from a dialog. > Any file users can manipulate today, they'll be able to manipulate > with a partially-Unicodeized Emacs. See above: for those, the Unicode interfaces give no advantage. > 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. But then this is just complication with no benefits, isn't it?