New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow a command to include history as a completion source #4344

Open
mqudsi opened this Issue Aug 19, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@mqudsi
Copy link
Contributor

mqudsi commented Aug 19, 2017

Perhaps for fish 3.0 we can include support for a completion script to indicate that its completions should come from fish's history file, so that tabbing would provide a list of matches from history. A lot of commands do not have local file completions, but are often used and reused from within a certain set of arguments, this would be a huge convenience for such commands.

To illustrate with a real-life example, I use autojump religiously (aliased to j as their setup routine does automatically under all supported shells). j watches your directory changes and learns what directories you use, so that when you type in - from any CWD - j foo it will take you to the directory you use most often that matches search pattern foo (even if foo is misspelled, an abbreviation, etc).

What would be amazingly convenient is if my previous usage of j were to be considered potential completions. So when I type in j f<TAB>, history entries such as j fish and j fish-shell could provide completions for the current command line, and the completions suggestions would list fish and fish-shell as options.

Other commands that I feel might benefit from this are ssh, ping, and other similar commands that are a) run often against the same targets, b) don't have "tangible" completions.

Additionally, any command that does not have completions but has history entries (basically while you are typing you get the ghost completion) can use this to complete from history, too.

@krader1961 krader1961 added this to the next-major milestone Aug 19, 2017

@krader1961

This comment has been minimized.

Copy link
Contributor

krader1961 commented Aug 19, 2017

Well ssh certainly has a "tangible" completion. But that aside the first question that comes to my mind is how this works with command history having more than one argument? Let's say you have a hypothetical command arglebargle And you've got these history entries:

arglebargle -v --word t-word -t -x
arglebargle -x --word y-word argx
arglebargle argx argy

What happens when I type arglebargle y[tab]? Does it give me arglebargle -x --word y-word argx and arglebargle argx argy as possible completions? Or nothing at all since no history entry has a second token beginning with the letter y?

It seems like this should be limited to commands with no completions. Otherwise how would the matching history entries be mixed into those from the explicit completions? But if it is limited to commands with no explicit completions then the user will see different behavior for the two cases which could be a source of confusion and annoyance.

Would it be better to implement something like zsh's incremental search? That has been requested many times. See, for example, issue #602.

@mqudsi

This comment has been minimized.

Copy link
Contributor

mqudsi commented Aug 21, 2017

I've been thinking some more about this and I feel like it actually has potential to become a great feature, if we tackle it right.

First, in answer to your question about which completion would be offered: none, since none match correctly (though fish has a habit I dislike of forcing completions when it thinks I made a typo).

Imagine if fish had a hypothetical "learning" completion source. Each time a command is executed successfully ($status == 0), fish can "learn" that the arguments are valid. This can be just another completion source, and would show up (perhaps in a different color) in the list of completions just as if an additional complete .... was used to add these entries.

If you executed

some_cmd foo #status = 0
some_cmd bar #status = 1
some_cmd foo bar #status 0
some_cmd alpha #status = 0

then at some later date typed in some_cmd <TAB>, the commands from above that exited with status 0 would be available as completions, probably tokenized. So that command would trigger a list of completions [foo, alpha]. And some_cmd foo <TAB> would trigger a completion for some_cmd foo bar.

@mqudsi

This comment has been minimized.

Copy link
Contributor

mqudsi commented Aug 21, 2017

Oh, and with regards to the zsh incremental search: that's not really what I'm looking for, the idea is to use muscle memory as much as possible so that the same workflow will work, so I don't have to "think" about whether I have a completion source installed for something and can the completions or if I need to search my history for the usage.

I have the excellent fzf completions script installed that can do all the ctrl+r stuff, but I almost never use it. fish' history search works well enough for me. Here's how it looks though, very spiffy:

fzf fish history

I would actually go so far as to recommend just bundling fzf instead of developing anything from scratch if we were ever to implement any of the suggestions for asynchronous completions UI, incremental search, etc. as it's both fast and sleek (it's asynchronous and populates in the background).

@krader1961

This comment has been minimized.

Copy link
Contributor

krader1961 commented Aug 21, 2017

I'm probably being dense but I don't see how this differs materially from the command history suggestion that is already shown and selectable by moving forward a char or the end of the line. And you can scroll back through matching history entries with [ctrl-P] or [up-arrow].

@mqudsi

This comment has been minimized.

Copy link
Contributor

mqudsi commented Aug 26, 2017

It's not about the result, it's about how you get there. You have to deal with the cognitive overhead of taking into account whether a completion is from history or from a completion script, whether to use tab/up or right arrow. Muscle memory is actively discouraged (and, in fact, harmful) without this feature.

mqudsi added a commit that referenced this issue Sep 21, 2017

Add history-based completions for autojump's j command
j does not have any "logical" source of completions, but it almost often
called with arguments that have been seen before (since it is used to
jump to favorite/recent directories). We can search the history for
possible completions and use those.

This is an example of the behavior mentioned in #4344 as a possible
enhancement for fish 3.0, where completions can be provided from history
if none are otherwise found.
@mqudsi

This comment has been minimized.

Copy link
Contributor

mqudsi commented Sep 21, 2017

In fa9e445, I implemented autocompletions for j (autojump) from history. This is basically the behavior I am proposing in this RFC, either as a complete parameter (--from-history or similar) or as a default fallback completion source when no completion source provides results that match.

@ridiculousfish

This comment has been minimized.

Copy link
Member

ridiculousfish commented Sep 23, 2017

I think this is a fantastic idea! It's a super-lightweight way for users to build their own completions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment