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 06:10:00 -0400 Message-ID: References: <4E2377E2.1020804@gmail.com> <4E23DA4A.1080301@gmail.com> <4E23FFB4.1040809@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1310983841 29160 80.91.229.12 (18 Jul 2011 10:10:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 10:10:41 +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 12:10:31 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 1QikmV-0001tB-6Z for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 12:10:31 +0200 Original-Received: from localhost ([::1]:55593 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QikmU-0005fE-0X for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 06:10:30 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:36470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qikm6-0005b6-Ab for emacs-devel@gnu.org; Mon, 18 Jul 2011 06:10:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qikm1-0002td-7h for emacs-devel@gnu.org; Mon, 18 Jul 2011 06:10:05 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:40679) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qikm1-0002tZ-0u for emacs-devel@gnu.org; Mon, 18 Jul 2011 06:10:01 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Qikm0-0001Ph-Gg; Mon, 18 Jul 2011 06:10:00 -0400 In-reply-to: <4E23FFB4.1040809@gmail.com> (message from Daniel Colascione on Mon, 18 Jul 2011 02:41:08 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:142096 Archived-At: > Date: Mon, 18 Jul 2011 02:41:08 -0700 > From: Daniel Colascione > CC: emacs-devel@gnu.org > > The 9X family is long dead. 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. > We shouldn't forgo technical improvement on the account of a dead > system. 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.) So this is the requirement: use the new APIs, but test safely for their availability and provide fallbacks for when they are not available. If the fallback does not use Unicode APIs, then it does not even need to be specifically tested on W9X, if that specific API is documented to exist on W9X. > > and (2) going Unicode means that all the existing APIs > > used by Emacs will have to be switched to Unicode. > > Why not do it piecemeal? We can directly call Unicode APIs where > appropriate. I'm not sure I understand the details of your proposal. The situation that worries me is this: . 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 . 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.