From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#13041: 24.2; diacritic-fold-search Date: Sun, 02 Dec 2012 23:31:20 +0200 Organization: JURTA Message-ID: <87txs4jgkv.fsf@mail.jurta.org> References: <20121130182205.C722F14B8D@panix1.panix.com> <87hao69b5r.fsf@mail.jurta.org> <20665.8224.844876.619203@panix5.panix.com> <87hao6zko4.fsf@mail.jurta.org> <83fw3qtboc.fsf@gnu.org> <87hao5jqu3.fsf@mail.jurta.org> <83wqx0s4jy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1354486136 9371 80.91.229.3 (2 Dec 2012 22:08:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Dec 2012 22:08:56 +0000 (UTC) Cc: perin@panix.com, 13041@debbugs.gnu.org, perin@acm.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 02 23:09:07 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1TfHie-000580-9I for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Dec 2012 23:09:00 +0100 Original-Received: from localhost ([::1]:55099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfHiS-0003E2-16 for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Dec 2012 17:08:48 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfHiO-0003Dl-Rg for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2012 17:08:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TfHiN-0003r4-Ry for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2012 17:08:44 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfHiN-0003r0-OP for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2012 17:08:43 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TfHkc-0003g6-9R for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2012 17:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Dec 2012 22:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13041 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13041-submit@debbugs.gnu.org id=B13041.135448621614057 (code B ref 13041); Sun, 02 Dec 2012 22:11:02 +0000 Original-Received: (at 13041) by debbugs.gnu.org; 2 Dec 2012 22:10:16 +0000 Original-Received: from localhost ([127.0.0.1]:50528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TfHjr-0003ef-Jp for submit@debbugs.gnu.org; Sun, 02 Dec 2012 17:10:15 -0500 Original-Received: from ps18281.dreamhost.com ([69.163.218.105]:59873 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TfHjo-0003eW-N0 for 13041@debbugs.gnu.org; Sun, 02 Dec 2012 17:10:13 -0500 Original-Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 44160451E187; Sun, 2 Dec 2012 14:07:52 -0800 (PST) In-Reply-To: <83wqx0s4jy.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 02 Dec 2012 20:16:17 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:67816 Archived-At: > IMO, using case tables for this is evil. If I want to "fold" > diacritics in search, that doesn't necessarily mean I want to fold the > letter-case as well. I might want doing that, or I might not; these > are two orthogonal features. `decomposition-table' is a separate char-table that has the subtype `case-table'. It should not conflict with the standard case table, so using `isearch-toggle-case-fold' should still toggle the usage of the standard case table. To toggle folding in the diacritics search perhaps requires having two decomposition tables: one where upper and lower case letters belong to one equivalence set, and another where they are in different sets, so `isearch-toggle-decomposition' could toggle between them. Or should the standard case table and the decomposition table be combined some other way? Maybe like the existing variable `case-fold-search' to add a new variable `decomposition-search' to enable/disable diacritics in search. > So we need a separate kind of char-table, one that could be installed > in addition to the case table, and one that will interpret nil as > an indication to ignore the character during search. I believe this kind of char-table should be based on the existing subtype `case-table' because it provides the features necessary for decomposition search such as extra table EQUIVALENCES (that permutes each equivalence class) and the extra table CANONICALIZE (where the canonical character is the final character in the recursion that traverses the `decomposition' property). > Then we will be able to ignore combining accents, as we indeed should. > We also need to modify the searching primitives to consult this new > table, in addition to case table. Yes, it seems the feature of ignoring combining accents (i.e. mapping some characters to nil) can't be added to existing case tables because for the case table this would mean that converting a string to upper case might delete some characters (like combining accents) and converting a string to lower case might add combining accents to the string that of course makes no sense. > IOW, I don't think we can implement this feature entirely in Lisp. > Some changes are needed on the C level as well. A hack that abuses the standard case table is already possible in Lisp. A complete implementation requires changes on the C level.