From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: case-table functions clobbering extra slots Date: Thu, 03 Feb 2005 01:40:10 -0500 Message-ID: References: <200501270316.MAA20608@etlken.m17n.org> <200501280007.JAA24856@etlken.m17n.org> <200501290053.JAA00216@etlken.m17n.org> <200501310021.JAA09264@etlken.m17n.org> <200502012320.IAA18638@etlken.m17n.org> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1107413256 19482 80.91.229.2 (3 Feb 2005 06:47:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Feb 2005 06:47:36 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org, fx@gnu.org, handa@m17n.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 03 07:47:35 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cwaly-0004wV-0C for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2005 07:47:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwazE-0001A9-Pt for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2005 02:01:08 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cwaw6-0007rP-Mo for emacs-devel@gnu.org; Thu, 03 Feb 2005 01:57:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cwaw4-0007qZ-VK for emacs-devel@gnu.org; Thu, 03 Feb 2005 01:57:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cwavy-0007mM-3O; Thu, 03 Feb 2005 01:57:46 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cwahk-0007c2-90; Thu, 03 Feb 2005 01:43:04 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Cwaew-0007io-T3; Thu, 03 Feb 2005 01:40:11 -0500 Original-To: snogglethorpe@gmail.com, miles@gnu.org In-reply-to: (message from Miles Bader on Wed, 2 Feb 2005 09:33:15 +0900) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:32793 gmane.emacs.pretest.bugs:5744 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32793 So the "dotted-uppercase-I to i" mapping could have a "non-reversible" flag, and the downcasing code would notice this when changing it to a normal "i", and put an `uppercase' text property on the result character. Then if the user subsequently did an upcase, the upcasing code could notice the `uppercase' property and properly change the normal "i" to a dotted-uppercase-I. This is not a useful way to handle the problem of `i' in Turkish. Every `i' has to upcase to dotted-uppercase-I, in Turkish. Doing it only for an `i' that has a special 'upcase' property would not be correct. Perhaps you are thinking of this property as a kind of cache mechanism. If so, the most it could achieve is to increase efficiency. We would still need some other mechanism to get correct results in general. So I think we should first design the other mechanism. If that mechanism turns out not to be fast enough, and if caching could make it faster, we could add caching. Something like the "suspicious flag" might work for that mechanism.