From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: =?iso-8859-1?q?AGAIN=3A_Can=27t_isearch_=27=F6=27?= Date: Thu, 08 Dec 2005 11:25:22 +0900 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1134008836 10078 80.91.229.2 (8 Dec 2005 02:27:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 8 Dec 2005 02:27:16 +0000 (UTC) Cc: romain@orebokech.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 08 03:27:07 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EkBTZ-0002qZ-S3 for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2005 03:25:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EkBTq-0001fd-AL for ged-emacs-devel@m.gmane.org; Wed, 07 Dec 2005 21:25:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EkBTd-0001f4-Li for emacs-devel@gnu.org; Wed, 07 Dec 2005 21:25:45 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EkBTc-0001er-Tz for emacs-devel@gnu.org; Wed, 07 Dec 2005 21:25:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EkBTc-0001em-Mu for emacs-devel@gnu.org; Wed, 07 Dec 2005 21:25:44 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EkBUY-0002a4-W7 for emacs-devel@gnu.org; Wed, 07 Dec 2005 21:26:43 -0500 Original-Received: from nfs.m17n.org (nfs.m17n.org [192.47.44.7]) by tsukuba.m17n.org (8.13.4/8.13.4/Debian-3) with ESMTP id jB82POBc028461; Thu, 8 Dec 2005 11:25:24 +0900 Original-Received: from etlken (etlken.m17n.org [192.47.44.125]) by nfs.m17n.org (8.13.4/8.13.4/Debian-3) with ESMTP id jB82POcQ028656; Thu, 8 Dec 2005 11:25:24 +0900 Original-Received: from handa by etlken with local (Exim 3.36 #1 (Debian)) id 1EkBTG-0004m2-00; Thu, 08 Dec 2005 11:25:22 +0900 Original-To: emacs-devel@gnu.org X-MIME-Autoconverted: from 8bit to quoted-printable by tsukuba.m17n.org id jB82POBc028461 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 Xref: news.gmane.org gmane.emacs.devel:47193 Archived-At: About a half year ago, we discussed this. > The original problem was that when a user have `=F6' of > iso-8859-15 in a buffer of iso-8859-15 coding system, he > can't isearch that character by typing `=F6' on his keyboard > because that key is recognized as `=F6' of iso-8859-1. >=20 > Stefan's proposal is to translate a character by > translation-table-for-input in read_char (). This is a > generic solution, but it makes read_char () return different > character depending on the buffer-file-coding-system of the > current buffer, which may or may not cause anther problem. >=20 > My proposal is to translate a character by > translate-table-for-input in isearch-process-search-char. > This is a limitted solution only for the current problem. And, RMS wrote: > Suppose we use the latter solution. We probably would want to use it > in other places as well, but which ones? Can you suggest a rule for > programmers to decide whether to translate the result from read-char > thru translate-table-for-input, and when not to? > Could you look thru the calls to read-char in Emacs, and see which > ones clearly should do this translation, which ones clearly should > not, and which ones would work right either with or without the > translation? As I didn't have a time for such a heavy study, I didn't respond anything, and the discussion has been inconclusive. At least, the rule is to trasnalte the result from read-char if it is compared with the characters in the current buffer. And, Luc correctly pointed out: > There is something that has not been pointed out in the summary Handa > gave, but which I believe may be relevant. If I understood correctly, > the problem in question will automatically completely disappear with > Unicode and hence with Emacs 23. (Unless I misunderstood.) I still don't have a time for the above study, but the problem should be fixed somehow. So, unless someone else can take over this matter, I propose again to install this change. Index: isearch.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v retrieving revision 1.277 diff -c -r1.277 isearch.el *** isearch.el 30 Nov 2005 22:53:00 -0000 1.277 --- isearch.el 8 Dec 2005 02:21:52 -0000 *************** *** 1809,1814 **** --- 1809,1816 ---- ((eq char ?|) (isearch-fallback t nil t))) =20 ;; Append the char to the search string, update the message and re-se= arch. + (if (char-table-p translation-table-for-input) + (setq char (or (aref translation-table-for-input char) char))) (isearch-process-search-string (char-to-string char) (if (>=3D char ?\200) --- Kenichi Handa handa@m17n.org