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: On language-dependent defaults for character-folding Date: Sun, 21 Feb 2016 18:31:23 +0200 Message-ID: <83povqm3dw.fsf@gnu.org> References: <83pow26svf.fsf@gnu.org> <87a8n5srbp.fsf@wanadoo.es> <83d1s17npz.fsf@gnu.org> <87oablfpn3.fsf@mail.linkov.net> <834mdd6llx.fsf@gnu.org> <7fbb8bc7-9a97-4bad-a103-a6690a35241d@default> <834mdc5w6o.fsf@gnu.org> <838u2hu6aq.fsf@gnu.org> <871t899tde.fsf@gnus.org> <83y4ahru04.fsf@gnu.org> <83fuwproyf.fsf@gnu.org> <837fi0sz29.fsf@gnu.org> <83egc8qzjh.fsf@gnu.org> <87egc7evu3.fsf@gnus.org> <83io1jpt4u.fsf@gnu.org> <87povqhj25.fsf@gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1456072322 3011 80.91.229.3 (21 Feb 2016 16:32:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Feb 2016 16:32:02 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: Elias =?utf-8?Q?M=C3=A5rtenson?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 21 17:31:56 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aXWvL-0005st-OU for ged-emacs-devel@m.gmane.org; Sun, 21 Feb 2016 17:31:55 +0100 Original-Received: from localhost ([::1]:42275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXWvH-0005yn-Ku for ged-emacs-devel@m.gmane.org; Sun, 21 Feb 2016 11:31:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXWv4-0005wk-Py for emacs-devel@gnu.org; Sun, 21 Feb 2016 11:31:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXWv1-0000EB-KW for emacs-devel@gnu.org; Sun, 21 Feb 2016 11:31:38 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXWv1-0000E7-Hk; Sun, 21 Feb 2016 11:31:35 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4138 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aXWv0-0005cO-Tr; Sun, 21 Feb 2016 11:31:35 -0500 In-reply-to: (message from Elias =?utf-8?Q?M=C3=A5rtenson?= on Sun, 21 Feb 2016 14:28:40 +0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:200387 Archived-At: > Date: Sun, 21 Feb 2016 14:28:40 +0800 > From: Elias Mårtenson > Cc: Eli Zaretskii , emacs-devel > > If that database gives us all that, then I'm all for using that database > instead of creating our own, of course. But why doesn't C-s o find ø, > and C-s l find ł then? > > Because under the Unicode decomposition rules, ø is not decomposable. I can't explain why that is the case (probably because there is no reason to have a combining /. I asked the question about this on the Unicode mailing list, let's see what we get in response. > After all, the only languages that use ø are languages that use it as a character of its own). Not sure what this means: how is the usage of ø in this regard different from, say, ä? > In the thread on the Unicode mailing list, the recommendation seems to be to use the CLDR (http://cldr.unicode.org/). Of course, this assumes there is a locale, but the choice of locale can easily be customisable (with the default being the user's locale). Not locale, language. > Another poster on the same thread mentioned that the CLDR doesn't go all the way, but adding a set of exceptions on top of it shouldn't be hard. In any case, the result would be significantly better than what is implemented now. The last part is not yet clear to me, as this aspect was never discussed in enough detail. I have now asked explicitly about that.