[IPython-user] Bug in keyseq_to_keyinfo
jorgen.stenarson at bostream.nu
Mon Oct 9 12:05:42 CDT 2006
Thanks for the report. I have added this as ticket #94 and will look
into it soon.
librik at panix.com skrev:
> 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.
> - David Librik
> librik at panix.com
> IPython-user mailing list
> IPython-user at scipy.org
More information about the IPython-user