Open purpleP opened 7 years ago
Keep in mind that fish has two distinct mechanisms: auto-suggestions and completions. The former is based on you command history. The latter on a combination of auto-generated or hand crafted completion commands plus auto-generated pathnames. Personally I like the fish approach. I can't tell from the proposal exactly how you intend auto-suggestions and pathname completions to interact.
@krader1961 Yeah, I know that. I use zsh-autosuggest plugin that emulates fish autosuggestions. And AFAIK autosuggestions aren't based only on history, but that doesn't matter. What matters is this.
C-f
) to accept history autosuggestion.I haven't used your shell, but AFAIK for some reason you still don't have this feature.
If you haven't used fish why do you think you are in a position to propose a significant change in its behavior?
@purpleP Thank you for taking the time to write this up. I understand this as a request for automatic tab completions. Instead of having to press tab, the completions appear as a menu automatically, as you type.
The main reason fish doesn't do this is that tab completions may be very expensive. For example the git
completion can invoke quite a lot of disk I/O. Autosuggestions are already viewed with suspicion, even though they work very hard to never create subprocesses, block the user's typing, etc. If fish were to invoke git
, etc. as the user types, it would be very excessive.
However we can imagine showing a menu of the "cheap completions" (history, etc) as the user types - basically all the autosuggestions instead of the best one. This seems reasonable to me: web browsers already work this way, for example. We'd have to think hard about the relationship in the UI between these cheap completions and tab completions. The relationship is already confusing: I certainly hit tab when I want to hit right arrow. But maybe it can be done.
I'm skeptical that this can work but happy to be proven wrong, if someone were to prototype it. Or if zsh has this as a plugin I'd love to try it.
@ridiculousfish Let's clarify something about expensive competitions. Disk IO on itself isn't a bad thing, right? So you could worry about things like: 1.Time it takes to get competitions.
The time doesn't matter, because the way this should work is when user typed character you would essentially create a Future that would have completions when it's done and if user typed a character before future is ready it's should be just canceled. I mean if completions are already asynchronous then they wouldn't block ui, right?
Disk health for reads is probably an issue in HDD and it's already a previous generation tech. And Intel and Toshiba have next generation non-volatile ROM that would be about a 1000 times faster than flash memory. You better be ready for future, right?
I think most of the time people use terminal at their home, so energy consumptions isn't much of an issue.
And while all this concerns are very real, I'd like to point out a thing that you seem to be missing here. It's users health and time.
I use ergodox ez keyboard, so for me tab is under my thumb, but all this time when I've used "normal" keyboard my pinky have hurted from pressing tab all the time. A lot of people have RSI in some degree or another. My colleague recently started to complain about his pinky, while he hadn't have problems for years. What I'm saying is that RSI is the real thing, pressing tab key can cause RSI and one day you bashing all those enters and tabs without any problems and the next day you have RSI and the medicine can only make some symptoms go, while the real problem is this tab presses (and many other things, but this is one of them).
Other thing is time. I bet that if you would ask users, what trade off they would take: their time or (disk health, energy consumption, etc) they would chose their time.
So about zsh plugin. That's what I wanted to do initially. Unfortunately zsh doesn't have interface for its completion features. So the only thing you can do (and some people have done it with some degree of success) is spawn a new shell, put the string that user typed there, imitate tab press, capture what zsh shows etc. I don't want to go this path.
About combining history and context autocomplete. This is very serious issue. And I think that the way I wanted to do that initially (showing two separate menus) is wrong, but I think I have a very nice solution. In vim there is a plugin called deoplete, that provides completions framework. What it does is it shows completions source (like tags, parser etc) along with completion itself. You could do that and by pressing some key combination user could dynamically chose what type of completions he would like to see now. So initially you show all types of completions and user choses what he want to see. Or user can set completions to initially show only history completions and if he presses some key, then you would show all completions. I hope you get the idea. Anyway this can be done nicely without confusing the users.
Now here is a similar tool https://github.com/microsoft/inshellisense , but the completion is terrible. Since the completion is defined here https://github.com/withfig/autocomplete/blob/master/src/ls.ts , and missing a lot of things.
@ridiculousfish there's a zsh plugin for this: https://github.com/marlonrichert/zsh-autocomplete. Some really cool stuff in this plugin that fish can get inspiration.
I haven't used your shell, but AFAIK for some reason you still don't have this feature.
AFAIK you already have zsh-style tab completion that can show all available options right? So if I would type (| means cursor)
~ cd ~|
and hitTAB
you will show all options like~ cd ~| ~/Downloads ~/Documents
right?So why not show them all always without me needing to press tab? I'm using zsh now and it really bothers me that in the 21st century at post Intellij area I have to press tab to see options in my shell. I mean, how is that even possible, are shell developers still leave in a cave or something?
On a serious note, this really hurts productivity if you're a fast touch typist.
So I'll explain what I'd like to see in shell.
The shell always shows available alternatives inside
{ option1 | option2 | option3 }
and highlights the first option.pressing enter now means executing
cd autocomplete
, meaning enter would always choose the first option (thinking about it in that case its probably better to wait for at least one character typed).~ cd a { **autocomplete** }
pressing/
. Forcd
this means accept suggestion but the command isn't complete yet.~ cd autocomplete/ { **code** | comics }
user can chose options with fuzzy-mathching.~ cd autocomplete/cm {**comics**}
Again, pressing/
accepts completion but not executes current command~ cd autocomplete/comics/ {**bar**}
Pressing enter now executescd autocomplete/comics/bar
as desired. With zsh I could also do this more effectively If I'm already familiar with content of the folderscd ~/a/c/b TAB
would transform intocd ~/autocomplete/comics/bar
, but that's very fragile thing and I rarely use it (doesn't work well with folder names containing_-
or anything like that. The number of keypresses it would take with my method is 8. If I would do the same while having to press tab every time I want to see options or chose between them this would take 10 which isn't much of a difference in this case, but the difference gets bigger with a bigger number of options.When the number of options is big almost every time I try to chose one by hitting tab multiple times I miss the options I need by one keypress and need to use arrow keys to get back and it's an awful experience.
One way in which this way of displaying options would fail is when the options list is very big and or when the options themselves are big like completions for command options. In this case it's better to use popup menu, but with same principles.