Repository navigation
Tab completion behaviour in new REPL #118878
Description
Activity
Hi @danielhollas and thanks for opening a bug report! I am also glad you are enjoying
core.py:)Regarding the problem, maybe I am missing something but this is the behaviour also with the old REPL. Check this out:
After a single TAB
After the second TAB
I am missing something?
Reacted by Daniel HollasOh wow, you're right 😅 So the jarring thing here is actually the fact that it is jumping up and down, since the menu is now dynamic and will disappear e.g. if you hit backspace. So I think it would make sense to change it and display it below (which is how ipython does it for example).
We can consider it as a feature for the future
Doing this would also solve a related navigation problem unique to the new REPL: Currently, if you're on a REPL line with completions showing above, typing Home or Ctrl+a will move the cursor to be in front of the first completion result, instead of to the start of the line being edited (or, to put it another way, immediately after the input prompt) where it "should" be.
Input otherwise works normally. If you start typing, the completions will disappear and the characters will go to the beginning of the input line. But it's disconcerting to see the cursor placed so far from where it "should" be.
@ferdnyc Interesting observation! It might be a good idea to open a new issue for the buggy behaviour you observed so we can track it independently.
And if you're up for it, it would be great if you could test whether my PR in #118939. If we can show it solved another bug, it could help pushing it through. :-)
@ferdnyc Interesting observation! It might be a good idea to open a new issue for the buggy behaviour you observed so we can track it independently.
Yeah, honestly I came here to report it (or to find where it was already reported, more likely), then saw this report and realized the change would make it moot.
And if you're up for it, it would be great if you could test whether my PR in #118939. If we can show it solved another bug, it could help pushing it through. :-)
Good idea. I suppose the other thing to check would be that End / Ctrl+e properly stops at the end of the input line, and doesn't go into the completions.
Reacted by Daniel HollasI suppose the other thing to check would be that End / Ctrl+e properly stops at the end of the input line, and doesn't go into the completions.
Confirmed, both start- and end-of-line keybindings work as expected in the PR's REPL.
...Not sure the initial
[not unique]completion response is really useful with completions under the input, though. It just adds an extra step to getting completion results.I know the old REPL technically had the same behavior (Tab in a position without unique completions just silently did nothing, the first time it's typed)... but showing a "[not unique]" message is sort of worse than nothing, in a way. If the display is going to be updated anyway, why not just show the completions?
That's how e.g.
zshhandles completions, though it's somewhat dependent on the number. If I'm on a shell line and typels<Tab>, it just shows me all 44 possible completions immediately. If I typel<Tab>, it asks,zsh: do you wish to see all 609 possibilities (305 lines)?Though, I will say that I like the handling of partially-unique results better now, as the '[not unique]' response is already streamlined.
In Python 3.12, after an
import sysconfig, interactions went like this:>>> sysconfig.g<tab> # Would automatically complete as far as >>> sysconfig.get_ # and stop. Then, >>> sysconfig.get_<tab> # would do nothing, until a second >>> sysconfig.get_<tab> # produced completion results
In the PR branch, after the same import,
>>> sysconfig.g<tab> # Updates the input to show, >>> sysconfig.get_ [not unique] # And then a second <tab> will show completions immediately
But this interaction still feels a bit clunky, in 3.13:
>>> import sysconfig >>> sysconfig.get_<tab> [not unique] >>> sysconfig.get_<tab> (completion results)
It's when the REPL has "nothing to add" to your initial input, that it feels like an extra step.
Reacted by Maxim MartynovThat's how e.g.
zshhandles completions, though it's somewhat dependent on the number. If I'm on a shell line and typels<Tab>, it just shows me all 44 possible completions immediately. If I typel<Tab>, it asks,zsh: do you wish to see all 609 possibilities (305 lines)?I realized I left out a form of completion interaction there — if I type
lsh<tab>in zsh, it completes as far aslshw— the unique prefix for all possible completions — and stops. A second<tab>will show the two possible completions oflshw:lshwitself andlshw-gui.So zsh is consistent with the new REPL, in that on a first
<tab>both will extend the input with unique completion characters and then stop, expecting a second<tab>to show the list of non-unique completions.The only difference is that zsh optimizes away the case where the user's input can't be extended, because there are only non-unique completions for the characters typed.
(Following @pablogsal on considering this as a feature, I removed the 3.13 label so to avoid backporting to 3.13)
- added a commit that references this issue
on Jan 23, 2025
Bug report
Bug description:
I've been playing a bit with the new REPL, it's so awesome! (thanks to @pablogsal and @ambv for the core.py episode 💌 )
I noticed a strange behaviour of the tab completion, whereas upon pressing the tab twice to show available options, the
>>>prompt jumps down and the options are displayed above it. Please tell me this is a bug and not a feature. 😅After a single TAB
After the second TAB
This is on Fedora 39, built with
./configure --with-readline, in Terminator terminal.Apologies if I missed something, happy to provide more info.
CPython versions tested on:
3.13
Operating systems tested on:
Linux
Linked PRs