From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: git on MacOSX and files with decomposed utf-8 file names Date: Thu, 17 Jan 2008 15:05:23 -0800 (PST) Message-ID: References: <478E1FED.5010801@web.de> <65026F2B-5CE8-4238-A9AB-D3545D336B41@sb.org> <200801162251.54219.jnareb@gmail.com> <1574A90A-8C45-46AD-9402-34AE6F582B3F@sb.org> <7652B11D-9B9F-45EA-9465-8294B701FE7C@sb.org> <8AC4CC86-A711-483D-9F9C-5F8497006A1D@sb.org> <87odbkyuvq.fsf@adler.orangeandbronze.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Wincent Colaiuta , Kevin Ballard , Jakub Narebski , Johannes Schindelin , Mark Junker , "git@vger.kernel.org" To: JM Ibanez X-From: git-owner@vger.kernel.org Fri Jan 18 00:07:00 2008 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1JFdoz-00014Q-Eh for gcvg-git-2@gmane.org; Fri, 18 Jan 2008 00:06:53 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757061AbYAQXGG (ORCPT ); Thu, 17 Jan 2008 18:06:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757055AbYAQXGE (ORCPT ); Thu, 17 Jan 2008 18:06:04 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:52767 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757169AbYAQXGB (ORCPT ); Thu, 17 Jan 2008 18:06:01 -0500 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [207.189.120.55]) by smtp2.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id m0HN5OLO002165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 15:05:25 -0800 Received: from localhost (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id m0HN5Nsm018471; Thu, 17 Jan 2008 15:05:23 -0800 In-Reply-To: <87odbkyuvq.fsf@adler.orangeandbronze.com> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) X-Spam-Status: No, hits=-2.715 required=5 tests=AWL,BAYES_00 X-Spam-Checker-Version: SpamAssassin 3.1.0-osdl_revision__1.47__ X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.53 on 207.189.120.14 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Fri, 18 Jan 2008, JM Ibanez wrote: > > With the exception of Unicode. If you check the standard, two Unicode > codepoints (i.e. the numeric value that gets stored on disk) *can* map > to the same character, hence they are the same. But if you want to make it clear, you can use "encoded character" or yes, "code point". But the thing is, even the unicode standard tends to just say "character", and a unicode string (for example) is defined to be a sequence of "code units" which in turn is about those *encoded* characters, which is all about the code points. So you'll find that they are very careful in some technical definition parts to talk about "code points", but then in other sequences they talk about "character" even though they are referring to the actual code point (ie the figure literally has the unicode number in it!) In fact, they sometimes even talk about "characters" in the totally non-encoding meaning of "glyph". So yes, "character" is often ambiguous. It would be good to never use the word at all, and only talk about "code point" and "glyph" and one of the well-defined special terms like "combining character" or "replacement character". But to take a representative example from The Unicode Standard, Chapter 2: "Unicode Design Principles": Characters are represented by code points that reside only in a memory representation, as strings in memory, on disk, or in data transmission. The Unicode Standard deals only with character codes. (any speling mistakes mine). In other words, from the very beginning of the standard, very basic design principles chapter, it starts talking about characters being represented by code points and explicitly says that it really only deals with CHARACTER CODES. Yes, I'm sure you can argue ad infinitum that all the "equivalences" and other crap means that a "character" can sometimes mean just about anything, but I'd say that it's pretty damn reasonable to equate "unicode character" with "code point" or "character code". Linus