peterh / liner

Pure Go line editor with history, inspired by linenoise
MIT License
1.04k stars 132 forks source link

Autocomplete Options #20

Closed ElPincheTopo closed 9 years ago

ElPincheTopo commented 9 years ago

When doing autocomplete I think that the autocomplete should be more similar to the one in bash. Right now, the behavior is to loop through the slice returned by the complete func. In bash the behavior is, when only one string is returned by the complete function, then it uses it, but when more than one can match then a list is displayed instead of doing the autocomplete. This example shows how bash complete works.

I think a good option would be to include an option to toggle the "type" of complete to use or to make a hybrid of them. When the complete function returns a slice with more than one option, at first imitate bash behavior, (double tab shows a list of the options) and then if you press tab again then start cycling though the slice.

I think this would be particularly good because some times you are not sure which option you want to use and cycling through the options is not as helpful in those cases as seeing all the options at once.

peterh commented 9 years ago

Thank you for your comments.

The way tab completion works is more like cmd.exe than bash. This was a deliberate decision. I use both on a daily basis, and I prefer cmd.exe style behaviour (in this specific case; bash is better in most other ways).

My main issue with bash is the first tab does nothing when there are multiple completion options, which is exactly the same behaviour as when there are zero completion options. There is no way for the user to tell if there are options that would be presented upon a subsequent press of the tab key, which is a terrible UX. There may be a beep, but there are no speakers connected in an office environment, so I don't hear it.

A secondary issue is I prefer my command line editors to not eat up vertical space. I prefer cycling through the options over scrolling previous interactions out of the window.

liner is intended to be simple, which is why there are few configuration options. That said, if you are passionate about this feature, I wouldn't reject a pull request without considering it first.

Note that there is nothing stopping you from writing to the console in the completion function, and liner will repaint the entire prompt when the completion function returns; you could implement a first-tab-press hybrid (if you are sufficiently careful) without modifying liner.

peterh commented 9 years ago

...except liner isn't reentrant, so you wouldn't be able to show the "There are a million possible completions. Would you like to destroy your entire scrollback buffer (y/n)?" prompt, so it wouldn't quite be a full hybrid.

ElPincheTopo commented 9 years ago

I have been using liner a while, and the problem I found with the current auto complete is that if there are many options available, (50+) then it's just awful to iterate over them, in this case the list does much more sense.

I get that the two-tabs for complete is annoying but it's just a matter of getting use to it, now I don't even notice it.

About the list options eating up all the vertical space, I think it's a nice compromise for the functionality it gives. Also I have use programs that have bash-like completion but after doing the completion they redraw the terminal, so it only takes the extra space while doing the completion.