-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Fish or ipython-like completion with tab key #43838
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
base: master
Are you sure you want to change the base?
Conversation
|
As long as there's a way to turn this off... |
|
Can you elaborate a little more? I would like to minimize configurable options so I want to know the reason. I think you lose nothing in terms of functionality because hitting a tab key only once just shows a list of candidates, which is the same as the current behavior (except underlines for highlighting matching prefixes). |
Instead of exiting completion mode, could it narrow the search? |
|
Could this be used with https://github.com/JunoLab/FuzzyCompletions.jl ? |
|
You mean like #40691? |
Yes, it is easy to implement. Indeed, I tried it before and it worked nicely. But I didn't do that in this pull request because neither fish nor ipython works in that way. I have no idea why but people may be more familiar with the fish/ipython-style behavior.
Also yes. This pull request doesn't touch the internal functions of completion and only UI functions are changed. So, I think it is easy to adopt third-party completion providers like FuzzyCompletions.jl. |
But the behavior after hitting the tab twice does change and tapping tab twice do sometimes have different behavior compared to a single tab even when it's not making a selection. For one, in current repl, by default (or at least I don't think I've made any non-default changes) tapping tab once isn't even doing anything so tapping twice is required anyway. Even if you think it's reasonable to expect the user to distinguish one tap and two tap accurately, distinguishing two and three+ when there isn't a behavioral difference is asking too much and I do often tap tab more than twice when trying to get completion. I highly doubt I'm alone on this. Also, in zsh, with minimal setting/by default, tapping twice is needed to show the full list of completion result when there are many pages. Now if the tab is just for highlighting one option but isn't going to put it in by default (and require a space/enter/right arrow to put it in) I could live with it, since then it won't be much different from paging and when I type manually after typing tab the bahavior isn't going to be different by too much. |
|
(so in short, the thing that is lost is when tapping tab multiple times and then trying to manually type more after seeing the completions to narrow down the options) Edit: and along this line the behavior from #43838 (comment) might be something I could live with, especially if it's accompanied by a hotkey (Esc/C-c/C-g etc) to abort the completion mode. The ipython terminal completion behavior was way too annoy for me for the reason I stated above. |
|
I got your point. The currently proposed implementation is a basis for further discussion, and I'm open-minded for new ideas and proposals.
Perhaps this point is the largest difference of our opinions. I would like to put a selected candidate in by default because it needs less typing and the user does not need to remember another keybinding to put it in. IMO, doing nothing with the first tab key, which is the current behavior of master, doesn't make sense. If there is a good reason to do so, I would like to know that. Narrowing down candidates as you type seems to be a nice feature to have, so if other people like it, too, I would like to adopt it in this pull request. Also, keybinding to abort completion is not implemented yet but it is in my task list. For our discussion, I've summarized below the current behaviors of julia (master), python, bash, ipython, fish, and zsh with the default setting when hitting tab keys several times in a row. Unfortunately, they are very inconsistent about tab completion. When there are few candidates:
EDIT: zsh was wrong. updated. When there are many candidates with the first tab:
|
And it show different pages on each tap, which is actually my favorate.
The select first behavior can be disabled (and I do) There's clearly a difference in the behavior when multiple hit of tab matters or not. For everything I use frequently, it doesn't matter and julia is also among them. I do see why someone may like to select the options automatically (fwiw, it's also the behavior of cmd on windows and that's actually where I have to face this behavior most often) and it's why I asked for a way to disable it. |
|
Currently I can hit tab, then type one additional character and hit tab again to filter the list of completions. If I accidentally hit tab twice and it has substituted a possible completion X for me, can I still hit a character to filter the original tab completion, or is the character I type appended to X? |
The latter is the proposed behavior (as in fish and ipython). I plan to implement a shortcut to abort completion even after you have selected a proposed one. If possible, I'd like to use |
|
Please do not complete to the first entry by default which requires users to hit backspace in order to narrow down based on the original. Because of JIT, two time and three time can be hard to distinguish, one can easily hit three times by accident, a delay after showing the list which if tab is pressed again would complete to the first word is possible but maybe annoying to implement As a compromise, I suggest tabbing never put in any words (so it wont ruin users ability to keep typing and narrowing things down), instead, an arrow key (or in vim style, ctrl-n) is needed. Honestly I really like this, and personally don't mind three-tabbing because I already use fish, but I see the problem of others have raised |
This is a proposal to introduce a fish/ipython-like completion feature to Julia's REPL. The current completion is not complete as it cannot select one from completion candidates. With this change, you can select one just by hitting the tab key several times. The following screencast demonstrates the behavior of proposed tab completion and navigation with arrow keys after

fi[Tab].This pull request is just a crude draft to demonstrate my proposal. If you like the idea, I'm happy to polish the code to review.
sum([tab](say), a list of methods is displayed (technically, this is not a completion).TODO