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: Re: kbd vs read-key-sequence Date: Mon, 19 Mar 2007 21:25:19 +0900 Message-ID: References: <45E8657D.4080202@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1174307158 19694 80.91.229.12 (19 Mar 2007 12:25:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 19 Mar 2007 12:25:58 +0000 (UTC) Cc: lekktu@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, jasonr@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 19 13:25:44 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 1HTGvo-0001LH-1X for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2007 13:25:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HTGxH-0003c4-IM for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2007 07:27:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HTGxE-0003bs-KN for emacs-devel@gnu.org; Mon, 19 Mar 2007 08:27:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HTGxC-0003bK-4S for emacs-devel@gnu.org; Mon, 19 Mar 2007 08:27:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HTGxC-0003bH-05 for emacs-devel@gnu.org; Mon, 19 Mar 2007 07:27:10 -0500 Original-Received: from mx1.aist.go.jp ([150.29.246.133]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HTGvZ-00025I-W3; Mon, 19 Mar 2007 08:25:30 -0400 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id l2JCPLuw029049; Mon, 19 Mar 2007 21:25:21 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id l2JCPLi7028065; Mon, 19 Mar 2007 21:25:21 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp1.aist.go.jp with ESMTP id l2JCPJRX019562; Mon, 19 Mar 2007 21:25:20 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken.m17n.org with local (Exim 4.63) (envelope-from ) id 1HTGvP-0005NP-UP; Mon, 19 Mar 2007 21:25:19 +0900 In-reply-to: (message from Richard Stallman on Mon, 19 Mar 2007 01:14:50 -0400) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.95 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) 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:68097 Archived-At: In article , Richard Stallman writes: > At first, encoded-kbd-mode is designed to be used in the > case that Emacs is invoked with -nw,=20 > I am not sure what that statement means. Does it mean that > encoded-kbd-mode was designed originally to be used in -nw > or does it mean that > encoded-kbd-mode is intended originally to be used in -nw > Which one? Both. It was designed to be used in -nw and it still keeps that design, and thus it is intended to be used in -nw. Please note that "decoding" means to convert a byte sequence to a character sequence. On terminal, what Emacs receives is surely a byte sequnece. But on windows, what Emacs receive is an window event, and it's a responsibility of window-event handler to convert it to a character event. And what window-event handler returns is a character, applying "decoding" on it is not the right thing. > 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. > That might be a good thing, but since you can't do it now, > can we fix encoded-kbd-mode to handle modifiers correctly? > It probably is not very hard. Implementing it in C doesn't solve the current problem. Still, Windows code should be fixed to generate a correct (multibyte) character event. And, once Windows code is fixed, we don't have to touch encoded-kbd-mode now. And, changing encoded-kbd-mode is not very hard, but hard enough to make me hesitate to do before the release. > > We could recommend that people write (meta ?). > > That would eliminate this particular problem, right? > No. It would make it work on those systems which have the bug (e.g. w32 > right now), but would not work on systems where read-key-sequence correct= ly > decodes such a key-combination into ?\M-=C3=A9. > I do not follow that argument. If users write (meta ?), > why would that cause any problem anywhere? Here, I think what he meant by "(meta ?)" is a code something like this ("\351" part is of 4 chars): (global-set-key [(meta ?\351)] ...) Then, it works only for w32. Another way is to visit .emacs as unibyte file, put "coding: raw-text;" tag, write as below ("\351" part is of 1 eight-bit char), and save it as raw-text. (global-set-key [(meta ?\351)] ...) But, this also works only for w32. Both depends on that the event ?\M-\351 is generated, but X generates ?\M-=C3=A9. > I don't think it'll really be reliable, but we can definitely provide > guidelines and hints. > One guideline is not to use encoded-kbd-mode on window > system. > What should be used instead? If there is nothing that works, > I suggest that people who care about Windows support either fix this > now, or implement something else now. I do suggest the former. I don't know how Windows port handles a keyboad event, but considering that it depends on encoded-kbd-mode to work, perhaps it returns a raw-byte (maybe with modifiers) sequence as a character event sequence. What it should do is to decode those raw-bytes by locale-coding-system. In emacs-unicode-2, I think it is much easier because I believe Windows itself has a facility to convert keyboard events to Unicode character. --- Kenichi Handa handa@m17n.org