Tab completion behaviour in new REPL

[danielhollas]

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

• gh-118878: Pyrepl: show completions menu below the current line #118939

[pablogsal]

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?

[danielhollas]

Oh 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).

[pablogsal]

We can consider it as a feature for the future

[ferdnyc]

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.

[danielhollas]

@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]

@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.

[ferdnyc]

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.

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. zsh handles completions, though it's somewhat dependent on the number. If I'm on a shell line and type ls<Tab>, it just shows me all 44 possible completions immediately. If I type l<Tab>, it asks,

zsh: do you wish to see all 609 possibilities (305 lines)?

[ferdnyc]

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.

[ferdnyc]

It might be a good idea to open a new issue for the buggy behaviour you observed so we can track it independently.

#126851 (Seen above, in the web interface.)

[ferdnyc]

That's how e.g. zsh handles completions, though it's somewhat dependent on the number. If I'm on a shell line and type ls<Tab>, it just shows me all 44 possible completions immediately. If I type l<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 as lshw — the unique prefix for all possible completions — and stops. A second <tab> will show the two possible completions of lshw: lshw itself and lshw-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.