This comes up every time Fish makes it to HN. It still bugs me too. So does up-arrow skipping the first matching history item and having to use right-arrow for the ghost entry that shows up. These two are 100% enough for me to change shells, and I will. Fingers crossed NuShell does well!

Can you describe what you like about NuShell? Never heard of it, but the Github page looks super interesting.

I struggle to imagine making use of it however. My normal flow just doesn't seem to need that power. I think I would benefit most from simplicity. Although, I could definitely see this benefiting from things being predictable, guessable, etc. Ie, when I rarely need more advanced features I'm less likely to need to look up documentation to figure out how to do something - as I often do.

Its line-editing and basic shell experience is not quite childproof yet (e.g. it can't parse tildes but only in Tmux), but I think it gets the balance right between being able to bash out a long pipeline quickly and having it work as you intended it. I have greatly enjoyed writing PowerShell in an IDE/VSCode, but not as a shell, but NuShell seems to capture the best bits in the line editor. I am most excited about the error reporting where it tells you about missing fields etc.

What's the problem with right arrow? I use ctrl+e (a la emacs) to accept the ghost completion.

Not OP, but I find myself attempting to tab-complete Fish commands all the time. It's just how I've been conditioned by every other auto-completion interface I've ever used.

Ok, here goes a rant. It isn't difficult to accept the completion. I'm complaining about an unnecessarily complicated mental model that is easy to trip up on, and requires much more thought to use. When you use zsh-history-substring-search, you can press up-arrow and scroll through history filtered by whatever you have entered so far. That is the end of the feature description. With fish, you have barely started.

Up arrow scrolls back through history. With the enormous caveat that it doesn't show you the most recent one, which is usually the correct one; the list is physically split into head and tail by two different keys and two different UIs, so you can't just use it like a list, you have to remember what the top is so you can choose whether to read the ghost entry or to up-arrow and read that. If you know what the most recent one is, you shouldn't have to read anything to check, you should just be able to press the right sequence of buttons that does what you want to do. (I can never be certain that the ghost entry is actually the most recent one, because I've always thought it was frecency-based, probably because that's what similar-looking search tools (Google) have taught me. That's mostly my fault, but it's not something the UI was actually capable of teaching properly because without having to press up-arrow to see it, it is not linked to any particular list ordering; it is conceptually distinct and users are within reason not to see it as part of that list at all.)

Up-arrow works differently depending on whether you have entered text in the line or not; no text and it show you the most recent, add text and it won't. And perhaps worst of all, up-arrow actually does show the most recently typed command, but only if the matching sequence of characters was not at the start of the line. Actually that's inaccurate -- if a command matches in the middle, but also as a prefix, you can't just remember that it matched in the middle and blindly press up-arrow. That's ghost-only.

So there are in fact three different lists that up-arrow could be scrolling you through. Actual history (includes most recent); filtered history where last command did not have search term as a prefix (includes most recent); and filtered history where last command had search term as a prefix (does not include most recent). This is no longer a job for muscle memory. It's an active thinking exercise. So you have to remember the history stack yourself, including where in each line your search text will match, so you can stop and pause to think whether to press up or right at any given moment. I cannot think of another search UI that requires knowing where in a string your search term will appear, just for basic use.

Ultimately, dozens of times a day, I stop to think about which button to press, and am reminded of this spectacularly poor UI, for which apparently nobody was able to express these sentiments in the four years that the GitHub issue was open. I don't believe the behaviour can be configured.

This is why I gave up on fish and went to zsh. It was always a headache.