Feature request: history-word-search-*?

[Korkman]

The history-token functions search the list of previously used arguments as they were passed to executed commands. This is great! There is one use-case, though, where I keep thinking "maybe there could be a better way":

in history:
ansible-playbook all.yml --limit first-host,second-host,third-host

later:
$ ansible-playbook all.yml --limit sec + history-token-search-backward
result:
$ ansible-playbook all.yml --limit first-host,second-host,third-host

What happens: the argument first-host,second-host,third-host is auto completed. This is great for auto completing arguments, but not partial arguments, which is what I frequently need, too. So I propose

new:
$ ansible-playbook all.yml --limit sec + history-word-search-backward
result:
$ ansible-playbook all.yml --limit second-host

also:
$ ansible-playbook all.yml --limit third-host,sec + history-word-search-backward
result:
$ ansible-playbook all.yml --limit third-host,second-host

[0ion9]

One conceptual question that comes up is: It hardly seems unlikely that I should want to complete successive parts of the full argument (eg sec -> second-host -> second-host,third-host).
Could such completion be a part of this proposition? If not, how should the gap of being able to complete one word, or one bigword ('history token'), but not N successive parts of the same bigword be explained to the user?

[Korkman]

Interesting. Useful, but kind of hard to implement and navigate. Consider this: On keypress, how to know whether to search for a longer or different word in history, opposed to appending the next part of the matching token? Also, which token? It's likely for a word to appear in many tokens.

I would rather limit this feature to completing and reverse searching for the typed word prefix:

sec -> second-host -> seconds

I would also leave it up to the user to append the separator, which can be space, comma, slash, period (... more?)
and will vary in different situations for the same word. Basically, typing a separator would end the reserve search.

So for your example it would be:

sec -> second-host

Type ,th, hit shortcut to new function

-> second-host,third-host

[0ion9]

Also, which token?

The token you already selected (if it is not clear which this is: AFAICS it must be the token in the most recent item within the history that matched the word). I'm trying to point out that you are selecting a subset of a token already, so the user can logically ask 'why can't I just complete even more (incrementally) of this token which is already selected?' (analogous to how you can use Tab-completion to complete part of a filename, type a bit to cut down options, and then Tab again to select the final completion)

I'd also add that your original proposal already implicitly incorporates assumptions about separator (word can be roughly defined as '1+ non-punctuation characters', in terms of what fish's *-word functions do); there are certainly different separators that may be relevant, but I think fish makes the assumption that the above definition of 'word' is good-enough for a majority of use cases.

Again, I'm not saying 'I totally want this thing that is a logical extension of your proposal'; I'm agnostic on whether that would be good. I'm just saying 'If your proposal was implemented, why would the user not expect the functionality to generalize to further words within the token?'

[Korkman]

it must be the token in the most recent item within the history that matched the word

Just typing sec does not select a token reliably. The most recent history item is not necessarily what I want. So a selection process must exist, and I'd go for history-word-search-backward and history-word-search-forward, replacing the word until the user is satisfied. Escape key (history-word-search-cancel?) might cancel the selection and revert to sec.

Actually, I can refine my previous post: The moment the user confirms the selection with a separator, the same function could progress the completion with matching tokens:

sec -> hotkey -> second-host

second-host, -> hotkey -> second-host,third-host

assuming first-host,second-host,fourth-host exists in history

Hit hotkey again

second-host,third-host -> second-host,fourth-host

So, grab all tokens matching the previous word (infix search), suggest the next word of the most recent token, scroll back in history when repeating hotkey.

To incorporate your suggestion, the remainder of the matched token could be printed in gray (just like current history autosuggestion), and partially be accepted in the same way (ctrl-right-arrow, is that forward-bigword?). I think that would be intuitive?

If computationally viable, the autosuggestion for token completion could always be shown.

So:

second-host,third-host -> ctrl-right key -> second-host,third-host -> ctrl-right -> second-host,third-host

or:

second-host,third-host -> end key -> second-host,third-host

But also, assuming fourth-host,third-host does not exist in history:

fourth-host -> ctrl-right key -> fourth-host

fourth-host, (no suggestion) -> fourth-host,third-host -> ctrl-right-arrow -> fourth-host,third-host

The keybinds history-word-search-backward and history-word-search-forward would then only be used to select different tokens based on the current word search.

Edit: when full line autosuggestion is found, it would have precedence.