From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: File name completion on Mac OS X with German umlauts Date: Thu, 13 Mar 2008 06:28:14 +0200 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1205382526 14619 80.91.229.12 (13 Mar 2008 04:28:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Mar 2008 04:28:46 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Juanma Barranquero Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Mar 13 05:29:13 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JZf44-0002mv-39 for geh-help-gnu-emacs@m.gmane.org; Thu, 13 Mar 2008 05:29:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZf3U-0005Sg-Uo for geh-help-gnu-emacs@m.gmane.org; Thu, 13 Mar 2008 00:28:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZf38-0005Pp-Om for help-gnu-emacs@gnu.org; Thu, 13 Mar 2008 00:28:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZf36-0005PU-Qj for help-gnu-emacs@gnu.org; Thu, 13 Mar 2008 00:28:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZf36-0005PR-KY for help-gnu-emacs@gnu.org; Thu, 13 Mar 2008 00:28:12 -0400 Original-Received: from mtaout1.012.net.il ([84.95.2.1]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JZf36-00062y-Fz for help-gnu-emacs@gnu.org; Thu, 13 Mar 2008 00:28:12 -0400 Original-Received: from HOME-C4E4A596F7 ([80.230.37.133]) by i_mtaout1.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0JXN007N2JPHXDN0@i_mtaout1.012.net.il> for help-gnu-emacs@gnu.org; Thu, 13 Mar 2008 06:41:42 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 9.1 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:52350 Archived-At: > Date: Thu, 13 Mar 2008 00:23:29 +0100 > From: "Juanma Barranquero" > Cc: help-gnu-emacs@gnu.org >=20 > On Wed, Mar 12, 2008 at 10:55 PM, Eli Zaretskii wrot= e: >=20 > > In particular, I don't see why file names with "X" and "=E2=85= =A9" are okay > > for you, but the two types of "=C3=BC" are not. I think they ar= e both > > exhibiting the same problem. >=20 > Well, the first two, U+0058 LATIN CAPITAL LETTER X and U+2169 ROMAN > NUMERAL TEN, are meant to be semantically distinct. >=20 > However, U+00FC LATIN SMALL LETTER U WITH DIAERESIS is supposed to = be > semantically identical to U+0075 LATIN SMALL LETTER U plus U+0308 > COMBINING DIAERESIS. In the first case, we're talking about differe= nt > abstract characters represented with different codepoints. In the > second case, we're talking about the same abstract character. Other > than a byte comparison, there is no distinction between both =C3= =BC. You > wouldn't expect a font supporting Unicode to represent U+00FC > different that U+0075 plus U+0308. I see no difference here: in both case the bytestreams are different. The fact that Unicode sees one case but not the other as two equivalent strings, is irrelevant here, because file names are not simple text strings, they have other semantics. Anyway, we are not talking about fonts, nor about Unicode decisions wrt character equivalency. We (at least I) were talking about the ``problem'' that several files have the same name if a file name is t= o be interpreted as a text string. As I said, I see no problem here, just entrenched customs.