Skip to content

Tab completion behaviour in new REPL #118878

Closed
#118939
Closed
Tab completion behaviour in new REPL#118878
#118939
Labels
stdlibStandard Library Python modules in the Lib/ directorytopic-replRelated to the interactive shelltype-featureA feature request or enhancement

Description

@danielhollas
danielhollas
opened on May 10, 2024

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

image

After the second TAB

image

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

Activity

  1. danielhollas
    added
    type-bugAn unexpected behavior, bug, or error
    on May 10, 2024
  2. aisk
    added
    3.13only security fixes
    on May 10, 2024

  3. pablogsal commented on May 10, 2024

    @pablogsal
    pablogsal
    on May 10, 2024
    Member

    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

    Screenshot 2024-05-10 at 10 09 55

    After the second TAB

    Screenshot 2024-05-10 at 10 10 08

    I am missing something?

  4. danielhollas commented on May 10, 2024

    @danielhollas
    danielhollas
    on May 10, 2024
    ContributorAuthor

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

  5. pablogsal commented on May 10, 2024

    @pablogsal
    pablogsal
    on May 10, 2024
    Member

    We can consider it as a feature for the future

  6. pablogsal
    added
    type-featureA feature request or enhancement
    and removed
    type-bugAn unexpected behavior, bug, or error
    on May 10, 2024
  7. AlexWaygood
    added
    topic-replRelated to the interactive shell
    on May 10, 2024
  8. danielhollas
    added 2 commits that reference this issue on May 11, 2024

    pythongh-118878: pyrepl: Show completion menu below current line

    a1d95c9

    pythongh-118878: pyrepl: Show completion menu below current line

    eae92aa
  9. lysnikolaou
    added
    3.14bugs and security fixes
    on Jun 12, 2024

  10. ferdnyc commented on Nov 14, 2024

    @ferdnyc
    ferdnyc
    on Nov 14, 2024
    Contributor

    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.

  11. danielhollas commented on Nov 14, 2024

    @danielhollas
    danielhollas
    on Nov 14, 2024
    ContributorAuthor

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

  12. ferdnyc commented on Nov 15, 2024

    @ferdnyc
    ferdnyc
    on Nov 15, 2024
    Contributor

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

  13. ferdnyc commented on Nov 15, 2024

    @ferdnyc
    ferdnyc
    on Nov 15, 2024
    Contributor

    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)?

  14. ferdnyc commented on Nov 15, 2024

    @ferdnyc
    ferdnyc
    on Nov 15, 2024
    Contributor

    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.

  15. ferdnyc commented on Nov 15, 2024

    @ferdnyc
    ferdnyc
    on Nov 15, 2024
    Contributor

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

  16. ferdnyc commented on Nov 15, 2024

    @ferdnyc
    ferdnyc
    on Nov 15, 2024
    Contributor

    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.

  17. picnixz
    removed
    3.13only security fixes
    3.14bugs and security fixes
    on Dec 15, 2024

  18. picnixz commented on Dec 15, 2024

    @picnixz
    picnixz
    on Dec 15, 2024
    Member

    (Following @pablogsal on considering this as a feature, I removed the 3.13 label so to avoid backporting to 3.13)

  19. picnixz
    added
    stdlibStandard Library Python modules in the Lib/ directory
    on Dec 15, 2024
  20. pablogsal
    added a commit that references this issue on Jan 21, 2025

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

    29caec6
  21. pablogsal
    closed this as completedin #118939on Jan 21, 2025
  22. miss-islington
    added a commit that references this issue on Jan 21, 2025

    pythongh-118878: Pyrepl: show completions menu below the current line (…

    0c94af4
  23. ambv
    added a commit that references this issue on Jan 23, 2025

    [3.13] gh-118878: Pyrepl: show completions menu below the current line (

    5c102a1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytopic-replRelated to the interactive shelltype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions