JuliaLang
History search no longer restores place in history
Consider typing
julia> 1 + 4
julia> v = ans
julia> "something else"
In pre-1.14 history r-search, doing ctrl-R+v+<UP>+<UP> accepts the v = ans search results and gives me 1+4 (and then I can do <DOWN> to get back v=ans after). This workflow no longer works with the new history search, for two reasons:
- After accepting an entry the cursor is at the entry, so hitting up does a prefix search
- The history place is not restored, so even
ctrl-A+<UP>gives me the most recent entry, not the entry from before the search result.
This is a significant regression - I use this workflow all the time. I'm willing to retrain my brain somewhat with new shortcuts, but I don't think they exist right now.
This was made more complicated with #60066 of course since multi history locations are now deduplicated.
I think I half understand what you're talking about with the old readline-style history search. I'm not sure I 100% follow though.
Given the entire interaction model has changed though, it would likely be more helpful to hear how you think the new UX model could be adjusted to work better.
Even worse <DOWN> doesn't go to the next entry reliably anymore. This really needs to be fixed. I don't think we can release 1.13 in this state.
Even worse doesn't go to the next entry reliably anymore.
Can you elaborate what this exactly means?
julia> 1 + 1
2
julia> 2 + 2
4
#<Ctrl-R>select 1+1
julia> 1 + 1
2
julia> # Hit down arrow -> should give 2 + 2
Yes it is very important to be able to Ctrl-R back to a point in the history, then start replaying multiple commands from there by hitting down arrow each time. This is one of the major improvements our REPL has made over most systems. If you just navigate history with up/down arrow and no search, it still works that way, so it ought to be easy to hook this up so that search is just a different way to pick a point in the history. As is it feels less consistent.
Setting the non-search "current history entry" state to the entry just inserted is an easy fix. The one question in my mind is when multiple history entries are selected whether we should set the state to based on the first or last entry?
Keno, I'm still not completely clear on what the overall problem you're describing in the initial comment is, particularly with (1). Given we now can have multiple match positions, since we're not just doing a single substring match, it would be more actionable if you could bundle the complaint with a suggestion on how this might work under the new system. This isn't a workflow I've used much myself, so it would be helpful to hear from somebody who has.
My suggestion would be to default to the last entry with some visual indicator that there are multiple matches (maybe could be a tweak on where we show the time right now) and then let me cycle through them with Ctrl-R/Ctrl-S. That's for selecting the place in history. As for the prefix search issue, we could try having Ctrl-UP always go up regardless of prefix. Or alternatively, we could invert it and disable prefix search on UP and require Ctrl-UP for it instead.
some visual indicator that there are multiple matches
We already have that (try pressing TAB on a few entries). Having subsequent Ctrl-R presses cycle through making the multiple recently inserted entries "current" seems like it would be a pretty poor UX to me, unless I'm mis-interpreting your suggestion?
Yes, you're misinterpreting my suggestion. I'm talking about the merging of multiple identical entries in the history that Kristoffer implemented. I don't know that I think that TAB feature is all that useful.