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
• [3.13] gh-118878: Pyrepl: show completions menu below the current line (GH-118939) #129161

[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. :-)