From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "D. Goel" Newsgroups: gmane.emacs.bugs Subject: Re: define-key #2 ---> ineffective if key is bound... Date: 21 May 2002 09:02:07 -0400 Organization: University of Maryland College Park Sender: bug-gnu-emacs-admin@gnu.org Message-ID: References: <200205202134.g4KLYXI26067@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1021986177 15529 127.0.0.1 (21 May 2002 13:02:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 21 May 2002 13:02:57 +0000 (UTC) Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17A9I0-00042D-00 for ; Tue, 21 May 2002 15:02:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17A9IU-0008Pt-00; Tue, 21 May 2002 09:03:26 -0400 Original-Received: from chx400.switch.ch ([130.59.10.2]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17A9HS-0008Me-00 for ; Tue, 21 May 2002 09:02:22 -0400 Original-Received: from grapevine.wam.umd.edu ([128.8.10.18]) by chx400.switch.ch with esmtp (Exim 3.20 #1) id 17A9HR-0006VZ-00 for gnu-emacs-bug@moderators.isc.org; Tue, 21 May 2002 15:02:21 +0200 Original-Received: from grapevine.wam.umd.edu (localhost [127.0.0.1]) by grapevine.wam.umd.edu (8.9.3/8.9.3) with SMTP id JAA17553 for ; Tue, 21 May 2002 09:02:10 -0400 (EDT) Original-Received: (from news@localhost) by grapevine.wam.umd.edu (8.9.3/8.9.3) id JAA17549 for gnu-emacs-bug@moderators.isc.org; Tue, 21 May 2002 09:02:10 -0400 (EDT) Original-To: gnu-emacs-bug@moderators.isc.org Original-Path: not-for-mail Original-Newsgroups: gnu.emacs.bug Original-Lines: 70 Original-NNTP-Posting-Host: poynting.umd.edu Original-X-Trace: grapevine.wam.umd.edu 1021986129 17546 128.8.86.100 (21 May 2002 13:02:09 GMT) Original-X-Complaints-To: abuse@wam.umd.edu Original-NNTP-Posting-Date: Tue, 21 May 2002 13:02:09 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Errors-To: bug-gnu-emacs-admin@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.bugs:1494 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:1494 > By viewing lossage, it emerges that when i press up-arrow, emacs sees > ESC o A instead of ESC O A. > > This shoudl not have happened, because if you look at the > function-key-map in the parent-mail, the function-key-map should have > translated this ESC O A into 'up' before this key-combination could > have ever reached key-translation-map. > > As soon as Emacs receives ESC O, key-translation-map goes to work. > function-key-map cannot go to work yet because Emacs has received only > part of the sequence that translates into the function key. RMS i had suspected the same.. i was looking at keyboard.c --- this is from line 8078: (this is where function-key-map is doing its work)----> +---- | /* If the best binding for the current key sequence is a keymap, or | we may be looking at a function key's escape sequence, keep on | reading. */ +---- It seems to me that the intention was: keep reading if we are in the middle of a possible function-key-sequence and if there are input-characters waiting.. .. and that IMHO, seems to be the way to do it.. when it will keep reading, it will see the next A and then it will convert the ESC O A into 'up before the thing ever reaches key-translation-map. Moreover, from the doc of the elisp-manual, +---- | - Variable: keyboard-translate-table | This variable is the translate table for keyboard characters. It | lets you reshuffle the keys on the keyboard without changing any | command bindings. Its value is normally a char-table, or else | `nil' +---- <-- thus, if the user wants to shuffle his O with P, then key-translation-map (rather than keyboard-translate-table) is the way to go. In the current version, it seems that there is no way for me to shuffle O with P without side-effects, either by using keyboard-translate-table or by using key-translation-map, because in both cases, the function-key-map's up-arrow conversion (and other arrows) gets broken. Shouldn't one of the two (key-translation-map and keyboard-translate-table) allow us this side-effect-free shiffling? if i got that right conceptually, would you like me to try to trace the 'bug' in keyboard.c ? D -- help get my Debian GNU/Linux see the surfboard-cable-modem? anyone?