define-key #2 ---> ineffective if key is bound...

define-key #2 ---> ineffective if key is bound...

[D. Goel]

This bug was discovered by Miles Bader...

If i do an emacs -q -no-site-file, and
then do a 

(define-key key-translation-map [O] [o])

this seems to have no effect.. viz. pressing O still self-inserts O.

However, if i now do a (global-unset-key "O"), then the translation
comes into effect.. viz. pressing O self-inserts o.

According to the elisp manual,  key-translation-map should not care
about thew bindings...  some more info about some var's is included at
the end..


In GNU Emacs 21.1.3 (alphaev56-dec-osf4.0f, X toolkit, Xaw3d scroll bars)
 of 2001-10-30 on shorty.csc.umd.edu
configured using `configure  --prefix=/usr/local/gnu --infodir=/usr/local/gnu/info/emacs-21.1 --with-kerberos --with-x --with-x-toolkit=yes --with-xpm --with-jpeg --with-tiff --with-gif --with-png'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:




Recent input:
ESC O A ESC O A ESC O A ESC O A ESC O A ESC O A ESC 
O A ESC O A ESC O A ESC O A ESC O A ESC O A C-v C-v 
C-v C-v C-v C-v ESC v ESC v ESC v ESC v ESC v ESC v 
ESC v C-c C-c n n n y ESC O A ESC O A = ESC O A ESC 
O A ESC O A ESC O A ESC x r e p o r t - e m a c s - 
b u g RET

Recent messages:
Mark set [6 times]
Loading newcomment...done
Mark set [3 times]
Auto-saving...done
scroll-signal-boundary-error: Beginning of buffer
Loading bbdb-snarf...done
Formatting...done.
Type C-x 4 b RET to restore old contents of the bbdb-list window.
Sending...done



BTW, when i do an emacs -q -no-site-file, the following is the value
of initial value of some relevant variables:



keyboard-translate-table
nil

extra-keyboard-modifiers
0

key-translation-map
(keymap (24 keymap (56 . iso-transl-ctl-x-8-map)))

function-key-map
(keymap (27 keymap (91 keymap (54 keymap (126 . [next])) (53 keymap
(126 . [prior])) (52 keymap (126 . [select])) (51 keymap (52 keymap
(126 . [f20])) (51 keymap (126 . [f19])) (50 keymap (126 . [f18])) (49
keymap (126 . [f17])) (126 . [delete])) (50 keymap (57 keymap (126
. [menu])) (56 keymap (126 . [help])) (54 keymap (126 . [f14])) (53
keymap (126 . [f13])) (52 keymap (126 . [f12])) (51 keymap (126
. [27])) (49 keymap (126 . [f10])) (48 keymap (126 . [f9])) (126
. [insert])) (49 keymap (57 keymap (126 . [f8])) (56 keymap (126
. [f7])) (55 keymap (126 . [f6])) (53 keymap (126 . [f5])) (52 keymap
(126 . [f4])) (51 keymap (126 . [f3])) (50 keymap (126 . [f2])) (49
keymap (126 . [f1])) (126 . [find]))) (79 keymap (121 . [kp-9]) (120
. [kp-8]) (119 . [kp-7]) (118 . [kp-6]) (117 . [kp-5]) (116 . [kp-4])
(115 . [kp-3]) (114 . [kp-2]) (113 . [kp-1]) (112 . [kp-0]) (111
. [kp-divide]) (110 . [kp-decimal]) (109 . [kp-subtract]) (77
. [kp-enter]) (108 . [kp-separator]) (107 . [kp-add]) (106
. [kp-multiply]) (73 . [kp-tab]) (83 . [kp-f4]) (82 . [kp-f3]) (81
. [kp-f2]) (80 . [kp-f1]) (66 . [down]) (67 . [right]) (65 . [up]) (68
. [left]))) (kp-equal . [61]) (kp-divide . [47]) (kp-decimal . [46])
(kp-subtract . [45]) (kp-separator . [44]) (kp-add . [43])
(kp-multiply . [42]) (kp-enter . [13]) (kp-tab . [9]) (kp-space
. [32]) (kp-9 . [57]) (kp-8 . [56]) (kp-7 . [55]) (kp-6 . [54]) (kp-5
. [53]) (kp-4 . [52]) (kp-3 . [51]) (kp-2 . [50]) (kp-1 . [49]) (kp-0
. [48]) (24 keymap (64 keymap (99 . event-apply-control-modifier) (83
. event-apply-shift-modifier) (97 . event-apply-alt-modifier) (109
. event-apply-meta-modifier) (115 . event-apply-super-modifier) (104
. event-apply-hyper-modifier))) (C-S-kp-9 . [C-S-prior]) (C-S-kp-8
. [C-S-up]) (C-S-kp-7 . [C-S-home]) (C-S-kp-6 . [C-S-right]) (C-S-kp-4
. [C-S-left]) (C-S-kp-3 . [C-S-next]) (C-S-kp-2 . [C-S-down])
(C-S-kp-1 . [C-S-end]) (S-kp-9 . [S-prior]) (S-kp-8 . [S-up]) (S-kp-7
. [S-home]) (S-kp-6 . [S-right]) (S-kp-4 . [S-left]) (S-kp-3
. [S-next]) (S-kp-2 . [S-down]) (S-kp-1 . [S-end]) (C-S-kp-prior
. [C-S-prior]) (C-S-kp-up . [C-S-up]) (C-S-kp-home . [C-S-home])
(C-S-kp-right . [C-S-right]) (C-S-kp-left . [C-S-left]) (C-S-kp-next
. [C-S-next]) (C-S-kp-down . [C-S-down]) (C-S-kp-end . [C-S-end])
(S-kp-prior . [S-prior]) (S-kp-up . [S-up]) (S-kp-home . [S-home])
(S-kp-right . [S-right]) (S-kp-left . [S-left]) (S-kp-next . [S-next])
(S-kp-down . [S-down]) (S-kp-end . [S-end]) (kp-delete . [127])
(delete . [127]) (backspace . [127]) (kp-insert . [insert]) (kp-begin
. [begin]) (kp-end . [end]) (M-kp-next . [M-next]) (kp-next . [next])
(kp-prior . [prior]) (kp-down . [down]) (kp-right . [right]) (kp-up
. [up]) (kp-left . [left]) (kp-home . [home]))

Re: define-key #2 ---> ineffective if key is bound...

[D. Goel]

i am Modifying the bug-report..  i was using [O] when i had meant to
use [?O], as pointed out by Kalle. 

now that i am using "O" instead of [O] as i had meant to, the
complaint has reverted back to the original complaint i had (posted in
g.e.help originally ) ---->


Start emacs -q -no-site-file.

Do a 
(define-key key-translation-map "O" "o")

<--works great, pressing O now inserts o.

The problem is that the up-arrow key stopes working..

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. 



The relevant variables on my TERM are in the parent mail of this
mail. 

Re: define-key #2 ---> ineffective if key is bound...

[Richard Stallman]

    If i do an emacs -q -no-site-file, and
    then do a 

    (define-key key-translation-map [O] [o])

Perhaps you meant (define-key key-translation-map [?O] [?o]).
O and o are symbols, which means they stand for function keys.

Re: define-key #2 ---> ineffective if key is bound...

[D. Goel]

RMS

> 
> Perhaps you meant (define-key key-translation-map [?O] [?o]).
> O and o are symbols, which means they stand for function keys.


indeed.. but see my follow-up to that bug-report.. there is another
bug.. that is the bug that had been bugging me from start..  viz. ?O
--> ?o in key-translation-map affects the behavior of up-arrow which
it shouldn't (because the function-key-map should have translated ESC O
A to up before the ESC O A reached the key-translation-map). 


D				   <http://www.glue.umd.edu/~deego/>
-- 
help get my Debian GNU/Linux see the surfboard-cable-modem? anyone?

Re: define-key #2 ---> ineffective if key is bound...

[Richard Stallman]

    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.

Re: define-key #2 ---> ineffective if key is bound...

[D. Goel]

>     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				   <http://www.glue.umd.edu/~deego/>
-- 
help get my Debian GNU/Linux see the surfboard-cable-modem? anyone?

Re: define-key #2 ---> ineffective if key is bound...

[Miles Bader]

"D. Goel" <deego@glue.umd.edu> writes:
> <-- 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.

I agree with you, mostly because my mental model of the relationship
between these various translation-maps (function-key-map ->
key-translation-map -> normal keymaps) is a pipeline, where later stages
cannot influence earlier ones.

However, in practice, this is not true, except for simple cases, because
function-key-map and key-translation-map work by modifying the tail of a
growing data structure, character by character, and pay attention to more
than one character at the end.

I suppose it could be worked around, by having two copies of the current
input sequence, one which holds the original input events, and which
function-key-map also modifies, which would be copied before
key-translation-map was applies (and presumably would have to be re-run
from either the beginning or some other synchronization point if
function-key-map actually shrunk the input).

But the key-lookup machinery seems very complicated and fragile to me, so
it may not be so easy to make such a change...

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]