From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: kbd vs read-key-sequence Date: Mon, 12 Mar 2007 23:12:12 -0400 Message-ID: References: <45E8657D.4080202@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1173755589 7885 80.91.229.12 (13 Mar 2007 03:13:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Mar 2007 03:13:09 +0000 (UTC) Cc: lekktu@gmail.com, emacs-devel@gnu.org, rms@gnu.org, jasonr@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 13 04:12:40 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HQxRE-0006dd-VI for ged-emacs-devel@m.gmane.org; Tue, 13 Mar 2007 04:12:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HQxRx-0003g6-Rv for ged-emacs-devel@m.gmane.org; Mon, 12 Mar 2007 22:13:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HQxRl-0003fn-Rg for emacs-devel@gnu.org; Mon, 12 Mar 2007 23:13:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HQxRj-0003fT-EK for emacs-devel@gnu.org; Mon, 12 Mar 2007 23:13:08 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HQxRj-0003fQ-8h for emacs-devel@gnu.org; Mon, 12 Mar 2007 22:13:07 -0500 Original-Received: from tomts13.bellnexxia.net ([209.226.175.34] helo=tomts13-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HQxQs-000228-2F; Mon, 12 Mar 2007 23:12:14 -0400 Original-Received: from pastel.home ([70.55.141.217]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070313031212.XCXN1593.tomts13-srv.bellnexxia.net@pastel.home>; Mon, 12 Mar 2007 23:12:12 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id B12667F6C; Mon, 12 Mar 2007 23:12:12 -0400 (EDT) In-Reply-To: (Kenichi Handa's message of "Tue\, 13 Mar 2007 10\:17\:10 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux) X-detected-kernel: Solaris 8 (1) 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:67839 Archived-At: >> > Because the way the event is decoded through read-key-sequence is >> > not necessarily the same. E.g. while ? may get turned >> > into ??, it may be the case that ?\M- stays unchanged. >> > How does that happen? >> See the OP. It seems that encoded-kb.el has such a limitation (it should >> probably be considered as a bug, but there may be good reasons for it, >> I don't know). > At first, encoded-kbd-mode is designed to be used in the case that Emacs > is invoked with -nw, and it uses key-translation-map to handle character > events from 0 to 255 (that's all what happens with -nw). That's true, so it's probably the reason for the limitation: all meta keys are expected to come with an ESC prefix, so the code has no good reason to handle ?\M- chars. > I think the following diagram is the right thing to do: > window-system terminal > | | > | window event | character event 0..255 > | | > handle_one_xevent keyboad-coding-system decoder > \ / > \ lispy event / > \ / > \ / > read_char > | > input method > | > keymap Agreed. > And, it's in my todo list to abolish encoded-kbd-mode and > implement keyboard-coding-system decoder in C for long, but > unfortunately I still don't have a time to do that. Does it have to be done in C? > As shown in the previous diagram, I think it's a bug of w32 > code if it doesn't convert such an event as ?\M- > into ?\M-=E9 because only a window system generates such an > event and knows how to encode it. Agreed. The bug is that w32 shouldn't be using encoded-kb. > One guideline is not to use encoded-kbd-mode on window system. But that's the only available way in w32, IIUC. Stefan