Move the readline import out of the top (module) level and add Jedi completion #350
Conversation
This fixes inducer#166. I have no idea why, but if readline is really libedit (like for a system or python.org install on Mac), it causes the built in shell to break the terminal inputs, but only when imported at the top level. If the import is deferred, as far as I've seen, it doesn't happen.
|
I wonder if we can actually use the SetPropogatingDict in Python 2 #330. Supposedly it doesn't work to pass a dict subclass to exec in Python 2, so maybe not. |
|
Thanks for this PR. I'm mostly OK with this, but I have two comments:
|
|
Ah you're right. If you |
This replaces rlcompleter, but it isn't a hard dependency. If we want to use rlcompleter, we should extract the completer from it so we can use it without importing readline (see inducer#350).
|
I've pushed a commit that uses jedi to do completion, if it is installed. We can also extract the rlcompleter completer and use it as a fallback if you like. I would try to do it without importing readline if possible, to avoid this stupid libedit issue. Unless someone knows of a way to detect libedit without importing readline (or if someone can figure out why importing libedit readline breaks urwid and how to fix it). |
|
We can copy this if we want basic |
|
This looks good to me. Ready to merge when you are. |
|
Let's see if the person who reported #352 or one of the other issues is able to test this first. |
|
Based on all the feedback we've received, it seems like this might be a win. @asmeurer, thoughts? |
|
Yeah I think we've had enough people confirm that this fixes this. |
This fixes #166. I have no idea why, but if readline is really libedit (like
for a system or python.org install on Mac), it causes the built in shell to
break the terminal inputs, but only when imported at the top level. If the
import is deferred, as far as I've seen, it doesn't happen.
CC @rofl0r