Re: define-key acting strange..

["D. Goel" <deego@glue.umd.edu>]

( A quick update before i go away for the long
weekend.. to... Maryland!!!.. )..


All of the problem was being caused by the one line in that
expression:  (guess i will have to wait another day to learn GDB :)


 (define-key [t] <foo>).. and that <foo> could be anything ..

Emacs is not frozen.. 'tis just that this line has the effect of
adding a (t . <foo>) to your keymap <-- Whether this result is a bug
or not, i am not sure..

Now depending on <foo> and the other bindings in the
key-translation-map, one might end up effectively getting a 'frozen'
emacs..

Consider this expression: (this is how i first traced that
                                      (not-really-a-)bug..)


(progn
  (message "DOING")
  (define-key key-translation-map [t] "f")
  (define-key key-translation-map "u" "v")
  (message "DONE")
  (goto-char (point-max))
  (insert (format "%s" key-translation-map))
  (write-file "~/gg.gg")
  )



After eval'ing this, key-translation-map looks like this: 
 (keymap (117 . v) (t . f) (24 keymap (56 . iso-transl-ctl-x-8-map)))


(117 is u...)..  Once you have this keymap, *everything* you type
inserts a f, except when you type u, which inserts v.  So, everything
is happening in accordance with key-translation-map, IMHO.
In the original expression, everything was getting mapped to
[T]... which just beeped at us .. what is [T] ?

BTW, up-arrow inserts 3 f's... guess why ? :) up-->ESC O A --> f f f  


Wishing a great weekend to all.. 

D				   <http://www.glue.umd.edu/~deego/>
-- 
Why don't *we* have congressmen like the one writing this!!! ---->
 http://www.gnu.org.pe/resmseng.html