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: Sat, 03 Mar 2007 18:01:08 -0500 Message-ID: References: <45E8657D.4080202@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1172962898 6145 80.91.229.12 (3 Mar 2007 23:01:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2007 23:01:38 +0000 (UTC) Cc: lekktu@gmail.com, jasonr@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 04 00:01:32 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 1HNdEK-0006ko-9Q for ged-emacs-devel@m.gmane.org; Sun, 04 Mar 2007 00:01:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNdEJ-00006D-Ti for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 18:01:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNdE2-0008Vo-9j for emacs-devel@gnu.org; Sat, 03 Mar 2007 18:01:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNdE0-0008Ut-8P for emacs-devel@gnu.org; Sat, 03 Mar 2007 18:01:13 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNdE0-0008Uq-1I for emacs-devel@gnu.org; Sat, 03 Mar 2007 18:01:12 -0500 Original-Received: from tomts5.bellnexxia.net ([209.226.175.25] helo=tomts5-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HNdDx-00067L-LJ; Sat, 03 Mar 2007 18:01:09 -0500 Original-Received: from pastel.home ([74.12.206.221]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070303230108.UDPP1671.tomts5-srv.bellnexxia.net@pastel.home>; Sat, 3 Mar 2007 18:01:08 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 25A6C80D1; Sat, 3 Mar 2007 18:01:08 -0500 (EST) In-Reply-To: (Richard Stallman's message of "Sat\, 03 Mar 2007 17\:13\:37 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.93 (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:67275 Archived-At: > Yeah, probably. But it's been the case sine Emacs-20. And some of the > bindings which worked in Emacs-20 failed in Emacs-21, and some of the > binding that work in Emacs-21 will fail in Emacs-22, and the same for > Emacs-23 most likely. And if you add modifiers it's even more likely > to fail. > I was not following this thread. Can someone summarize the problem > as it is known? Here is the problem: when a key is pressed which causes a non-ASCII char to be inserted in a buffer, the translation from the key-event to the non-ASCII char can happen at many different levels: - before the event is passed to Lisp code - in input-method - in key-translation-map (using encoded-kb typically) - in self-insert-command (using unibyte-char-to-multibyte) Usually, the earlier the better, but historically we started by doing the most case of the translation (e.g. latin-1) in self-insert-command. Also the place where it's done depends on the kind of char, the kind of input method (e.g. XIM or LEIM), whether we're in console mode or w32, or X11, or ... On the other side of the problem we have code written in the .emacs file which tries to bind something to this key. To work, this has to satisfy the condition that when Emacs loads the .emacs file, the key it finds in the define-key call corresponds to the form of the event after key-translation-map (but before unibyte-char-to-multibyte if applicable). An additional piece of the puzzle is that the key that Emacs finds in the define-key call might not be the one that the user sees on her screen when she edits her .emacs, depending on how she specifies the file's encoding. Another source of fun is of course the lack/presence of unification which means that the same glyph or char can have different codes. And if you want it to work with modifiers, it's yet a bit more interesting because the base-event is not always decoded (partly because of bugs, I guess, but in some cases it's done on purpose. IIRC an example of purposefully keeping the base event untranslated is for cyrillic input-method where `c' might map to a cyrillic char, but C-c and M-c should stay unchanged). Stefan