Comment 10 for bug 1018996

Revision history for this message
Yaroslav Halchenko (yarikoptic) wrote :

Thanks Andreas -- tried it -- I guess it is better now...

so, now if I have pre-split window with an original source code in one (#1), and the interactive ipython in another (#2), completing in ipython shell uses the #1. Then whenever I am done completing I have following options to "close" it to get back to the code view: switch to it and press 'q' or actually complete completion by clicking mouse on a desired choice -- then completion buffer gets removed going back to #1 with the source code. And then if I just triple-Esc -- it closes ALL other buffers and I end up with the mighty shell. And I guess that is how other shells completions behave (tested with a regular shell). I just wondered what is your usage pattern? do you just keep completions buffer pre-opened all the time? or use mouse/switch+q to close it? Ideally, I wished there was a way to close completions buffer without leaving the prompt buffer and without hurting any previously opened (e.g. code view in #1) as if I pressed 'q' in it... e.g. if Triple-Esc (keyboard-escape-quit) could be overriden to invoke that action in the "*Python Completions". Or may be there is already some shortcut which would accomplish this?

An "interesting" side effect I ran into while playing with it
- if I quickly press tab 2 (or more) times, besides progressing to the first choice (and additional tab if more than twice tab was pressed) inserted after the completion, a previous prompt in the buffer might obtain a list of all possible completions ";"-separated, e.g.:

 [10]: np.array;np.array2string;np.array_equal;np.array_equiv;np.array_repr;np.array_split;np.array_str

In [12]: np.array

and then some times even cursor jumps to that line (instead that last prompt where I was trying to complete).
Have you ran into it?