RFC: Tweak Ctrl-R history position behavior
When we switched to the new ^R widget, we lost a very useful workflow
of finding a particular history entry, going back to it and then
executing the statements in order from that position by hitting the down
key. There are three distinct issues:
1. The history searcher doesn't currently set the history index of the
entry it restores at all.
2. Accepting an entry puts the cursor at the end, so UP is prefix
search, not history navigation.
3. The searcher dedupllicates multiple entries, so you may not
necessarily get the right one (this may seem niche, but it's
not - I frequently want to go to the sequence *before* the last
one, because I messed something up and had to restart the REPL
and want to start clean).
This is a vibe-coded PR that tries to prototype solutions to all
three. Since these things are a bit taste dependent, I have put no
effort into implementation cleanup for the time being, while we decide
on what we want the behavior to be.
Currently this PR does the following:
1. Fixes the lack of history entry restoration.
2. Always puts the cursor at the start of the line after accepting a
history entry. For consistency, also put the cursor at the start of
the line, when navigating to a previous history entry. We used to
have a hidden modal that disabled prefix search if and only if the
immediate previous thing you did was a history navigation. However,
because this modal was invisible it was a frequent cause of
confusion. This removes it. Fixes #24084.
3. Adds a xN tag for history entries with `N` duplicates. These can be
expanded with RIGHT to select a particular entry in the history. If
not selected, defaults to the most recent entry.
Fixes #60144
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
