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: One more string functions change Date: Sat, 28 Jun 2014 20:19:56 +0300 Message-ID: <83zjgx54ub.fsf@gnu.org> References: <53AD8D59.5000207@yandex.ru> <53AD9FDB.80705@cs.ucla.edu> <83simq6spc.fsf@gnu.org> <53AEEBA3.1030706@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1403976030 3618 80.91.229.3 (28 Jun 2014 17:20:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Jun 2014 17:20:30 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 28 19:20:25 2014 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 1X0wIX-0007F2-1v for ged-emacs-devel@m.gmane.org; Sat, 28 Jun 2014 19:20:21 +0200 Original-Received: from localhost ([::1]:55414 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0wIW-0002o8-L8 for ged-emacs-devel@m.gmane.org; Sat, 28 Jun 2014 13:20:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0wIP-0002js-Rs for emacs-devel@gnu.org; Sat, 28 Jun 2014 13:20:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0wIK-0001De-MG for emacs-devel@gnu.org; Sat, 28 Jun 2014 13:20:13 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:50429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0wIK-0001CS-EC for emacs-devel@gnu.org; Sat, 28 Jun 2014 13:20:08 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N7W00M002EDAA00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 28 Jun 2014 20:20:06 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7W00MYB2TI4I80@a-mtaout22.012.net.il>; Sat, 28 Jun 2014 20:20:06 +0300 (IDT) In-reply-to: <53AEEBA3.1030706@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:172803 Archived-At: > Date: Sat, 28 Jun 2014 20:21:55 +0400 > From: Dmitry Antipov > CC: Paul Eggert , emacs-devel@gnu.org > > On 06/27/2014 11:46 PM, Eli Zaretskii wrote: > > > That's not enough. Currently, Emacs down-cases using the current > > buffer's settings. This is TRT in some cases, but very wrong in > > others. It is especially wrong when down-casing strings (as opposed > > to portions of a buffer), because there's no reason to believe that a > > particular string being processed has any relevance to the current > > buffer and its defaults. > > What makes you think that the system locale is more relevant? I didn't say it was. I said that we currently have no way of telling Emacs to down-case in a locale-specific manner: > > IOW, we don't have any good way of specifying language- or > > locale-specific case-folding. > > What's wrong with case tables? They are not locale- and/or language-specific. For example, down-casing 'I' to 'i' is wrong for Turkish. > If we're talking about Unicode only, is it enough/possible/desirable > to have just one (huge) case table for all supported characters? You can't, because language-specific rules interfere. See section 5.18 in the Unicode Standard, and the SpecialCasing.txt file in the Unicode Character Database. > > FWIW, I think _that_ is where we should concentrate our energy, not on > > nano-improvements such as the one proposed here. But hey! 90% of > > Emacs development energy goes to such changes, while important missing > > features are being left unimplemented for years. So who am I to > > complain? > > "Why are you being so harsh? We are not the enemy" (C). Sorry about that. > If you have a personal TOTO/wishlist/roadmap/whatever, please share. In the department we are talking about, look at the links on this page: http://www.unicode.org/reports/ UAX#14, UAX#15, UTS#10, and UTS#18 should all be supported by Emacs. (And yes, I should complete my work on bringing the bidirectional editing support in line with the additions to UAX#9 in Unicode 6.3.) Elsewhere, the recent IDE and WYSIWYG editing discussions suggest major improvements in functionality that at least some users sorely miss. The FFI stuff (see on-going discussions here) is yet another. And that's just results of a 10-sec thought.