From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: =?iso-8859-1?q?Re=3A_Can=27t_isearch_=27=F6=27?= Date: Mon, 18 Apr 2005 11:52:33 +0900 (JST) Message-ID: <200504180252.LAA20878@etlken.m17n.org> References: <296c27822efac3bf0271bf82f19ca485@Web.DE> <606b3ca39653eb6a62837e841402d5c8@Web.DE> <87fyxtxwku.fsf-monnier+emacs@gnu.org> <200504142342.IAA12606@etlken.m17n.org> <87br8g2pe0.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1113793393 27797 80.91.229.2 (18 Apr 2005 03:03:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 18 Apr 2005 03:03:13 +0000 (UTC) Cc: Peter_Dyballa@Web.DE, emacs-pretest-bug@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 18 05:03:05 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DNMXN-0004Dy-T8 for ged-emacs-devel@m.gmane.org; Mon, 18 Apr 2005 05:03:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DNMbP-00075e-ID for ged-emacs-devel@m.gmane.org; Sun, 17 Apr 2005 23:07:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DNMZb-0006uS-21 for emacs-devel@gnu.org; Sun, 17 Apr 2005 23:05:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DNMZC-0006mB-Bl for emacs-devel@gnu.org; Sun, 17 Apr 2005 23:04:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DNMZC-0006jw-66; Sun, 17 Apr 2005 23:04:54 -0400 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 1DNMOl-0000d1-D8; Sun, 17 Apr 2005 22:54:08 -0400 Original-Received: from nfs.m17n.org (nfs.m17n.org [192.47.44.7]) by tsukuba.m17n.org (8.12.3/8.12.3/Debian-7.1) with ESMTP id j3I2qYdY007326; Mon, 18 Apr 2005 11:52:36 +0900 Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by nfs.m17n.org (8.12.3/8.12.3/Debian-7.1) with ESMTP id j3I2qXDI014264; Mon, 18 Apr 2005 11:52:33 +0900 Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id LAA20878; Mon, 18 Apr 2005 11:52:33 +0900 (JST) Original-To: Stefan Monnier In-reply-to: <87br8g2pe0.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 15 Apr 2005 08:36:40 -0400) 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:36071 gmane.emacs.pretest.bugs:7027 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36071 In article <87br8g2pe0.fsf-monnier+emacs@gnu.org>, Stefan Monnier writes: >>> Hmm... indeed the translation-table-for-input is not used for X11 keys. >>> Now that I look at it a bit more, I think the patch below would make sense. >>> What do other people think? >> That doesn't work in some case. The value of >> translation-table-for-input can be different in each buffer >> (depending of buffer-file-coding-system of a buffer). > Of course, that's why we can't do directly it in the > xkeysym-> char conversion. But it seems like doing it in read-char > should work. I don't know the diffence between them because even read-char doesn't know how a caller will treat the returned character. > Can you show me an existing piece of code where it wouldn't > work right? No, I can't. But shouldn't we avoid such an incompatible change at this stage? > Hypothetical examples aren't too interesting since we can also > concoct such examples where the current "translate in > self-insert-command" can be made to fail. I didn't know that self-insert-cmmand also uses translation-table-for-input. I have thought that the variable is for an input method as in this docstring: Char table for translating self-inserting characters. This is applied to the result of input methods, not their input. See also `keyboard-translate-table'. Anyway, could you show me such an example? --- Ken'ichi HANDA handa@m17n.org