gh-120767: Add REPL history navigation with partial text

[estyxx]

cc @pablogsal

These changes add support for navigating the REPL history with the up arrow key based on partial text in the buffer.

When partial text is in the buffer, the up arrow key will navigate through history entries that start with this partial text.

Example:

>>> spam = 1
>>> ham = 2
>>> eggs = 3
>>> sp
<arrow-up>

This correctly shows spam = 1.

With the following history:

>>> a=1111
>>> a=111
>>> a=11
>>> a=1

Typing a= and pressing the up arrow key will correctly navigate to a=1 and up.

Preserving existing behaviour

The standard navigation remains intact, ensuring that pressing the up arrow key without partial text continues to retrieve the most recent history entry. For example:

>>> 1+1
>>> 2+2

first <arrow-up> shows 2+2, second <arrow-up> shows 1+1.

• Issue: The New REPL Command History Does Not Honor Partial Text #120767

[ghost]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[vstinner]

Please see also PR gh-123607 and issue gh-119034: it seems like this PR is similar to gh-123607, but different. It's unclear to me if differences are made by purpose or not.

I don't know well readline and inputrc default configuration per operating system. I'm a Fedora user where PageUp and PageDown are mapping to:

$ grep history-search /etc/inputrc 
"\e[5~": history-search-backward
"\e[6~": history-search-forward

@estyxx: Would you mind to play with my PR gh-123607 and see if we can converge to the same behavior?

[estyxx]

@estyxx: Would you mind to play with my PR gh-123607 and see if we can converge to the same behavior?

Sure I will have a look!

[ambv]

For 3.13 we're supporting Page Up and Page Down keys to do strict "current-line prefix search". This supports multiline entries.

For your PR, Ester, it's unclear to me what to do in case of multiline entries. WDYT?

[pablogsal]

Given that this is supposed to emulate

#120767 (comment)

I think this should do the same as arrow up/down because it uses the same bindings as that inputrc file.

[estyxx]

@pablogsal @ambv
So, after looking at PR #123607, I see it already handles similar functionality. Their approach of keeping the cursor where it is during a history search seems better. I’ve updated my PR to rebind the arrow keys to work the same as PageUp and PageDown for prefix-based history search.

Regarding multiline commands, I initially wasn't sure if the desired behavior was to skip entire blocks or handle them line by line when navigating. However, after working with the PR, the actual behavior seems okay to me: it displays the multiline commands entirely and navigates line by line, skipping all the lines during the search.

I am currently working to fix the tests.

While debugging I noticed an unexpected behavior:

cc @vstinner

Regarding the issue mentioned in the comment here:

The behavior works as expected, but in the following case:

>>> import os 
>>> imp|
[page-up]
>>> imp|ort os 
[page down]
>>> imp|ort os 

The prompt gets stuck to the last match.
Instead, I was expecting it to come back to:

>>> imp|

as this is the old REPL behavior.

I have identified the issue and can fix it in this PR or a separate one. Let me know your preference.

To recap, this PR now only rebinds the arrow keys to the same functionality as PageUp and PageDown, i.e., searching the history.

[vstinner]

The prompt gets stuck to the last match.

I don't know how to fix this behavior :-( Feel free to propose a fix.

[vstinner]

To recap, this PR now only rebinds the arrow keys to the same functionality as PageUp and PageDown, i.e., searching the history.

LGTM

[vstinner]

Suggested change

	Enhance REPL history navigation with partial text support
	The REPL now correctly navigates history based on partial text
	in the buffer when using the up arrow.
	Enhance REPL history navigation with partial text support.
	The REPL now correctly navigates history based on partial text
	in the buffer when using the up arrow.

[hroncok]

I'd be careful with the word correctly here, as it could mean many different things.

[vstinner]

This behavior is different than Python 3.12 REPL (on Fedora).

$ python3.12
>>> import email
>>> import asyncio
>>> 1+1
2
>>> imp

If I press UP key, I get 1+1, not imp|ort asyncio.

I'm not sure which behavior is the most convenient / the least surprising. Should we keep UP/DOWN to only navigate in the history without partial match?

cc @hroncok

[hroncok]

I'm not sure which behavior is the most convenient / the least surprising.

I have as many personal opinions on the matter as anyone involved. Sticking to the facts instead:

• The readline/inputrc default for arrow up and arrow down is to traverse the history regardless of what is already written to the prompt¹.
• This proposed change is based on custom inputrc.
• The proposed functionality is already bound to PgDown/PgUp.
• Parsing and following custom inputrc was rejected as out of scope.

Footnotes

1. no link to back that up, but this is how Python 3.12 REPL behaves without custom inputrc ↩

The change is technically correct, but I'm not sure if the change makes sense. I prefer to remove my approval for now.

[estyxx]

Hi all,

I see that there are many differing opinions regarding the need for this feature. Before proceeding with fixing the tests and investing more time into this, I would like to get a clearer sense of whether the community wants...

In the meantime, I’ve identified a related bug which I mentioned in a previous in this comment. �This bug seems to be a definite issue with the current implementation, so I plan to open a separate issue and submit a PR to address it.

Please let me know if it’s worth continuing with the current approach or if any adjustments would be more suitable.

Thanks in advance for your feedback!

[vstinner]

This bug seems to be a definite issue with the current implementation, so I plan to open a separate issue and submit a PR to address it.

That sounds like a good idea :-)