Dear IPython and pyReadLine hackers,
The function keyseq_to_keyinfo() in keysyms.py (in pyReadLine,
used on Windows as part of Ipython) has some code in it to
support key sequences of multiple characters, in particular
key sequences that start with \e, meaning "escape".
This code is wrong and must be removed; it leads to damage
to the pyReadLine key bindings.
keyseq_to_keyinfo converts a keychord specification like
"C-m" (meaning Control-M) to a keyinfo tuple. It returns
a single tuple indicating the key pressed, plus the state
of the control, meta, and shift keys.
But the "elif" clauses that try to support \e (escape) and
len(keyseq) > 1 append tuples to a list called res. Nothing
is ever done with most of that list; the function simply returns
the list's first element. So all key sequences with multiple
characters are treated as though they only had one character.
This causes trouble, since IPython's default "ipythonrc" file
contains the following lines:
# I also like to have the same functionality on the plain arrow keys. If you'd
# rather have the arrows use all the history (and not just match what you've
# typed so far), comment out or delete the next two lines.
readline_parse_and_bind "\e[A": history-search-backward
readline_parse_and_bind "\e[B": history-search-forward
That doesn't do what the author probably thinks. It just
remaps "Escape" to history-search-backward, and then remaps
it again to history-search-forward. This destroys the user's
binding of "Escape", as well as pyReadLine's binding of it to
the prefix_meta function.
So the easiest fix is to remove those lines from "ipythonrc".
Then keyseq_to_keyinfo should be rewritten to avoid appending
to the res list. I.e., remove the \e clause and the multi-
character sequence clause, since they can't be done right
given the current design of how pyReadLine key bindings work.
Thanks,
- David Librik
librik@panix.com
_
IPython-user mailing list
IPython-user@scipy.org
http://projects.scipy.org/mailman/listinfo/ipython-user
