-
-
Notifications
You must be signed in to change notification settings - Fork 85
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
Inconsistent behaviour from completion #459
Comments
That is unrelated. As I already mentioned, the absence of the You've noticed that the cache for the
In this context, both command and variable names are generated as candidates. However, if the number of generated command names is larger than the limit set by
When a menu is already open, the completion is performed within the candidates shown in the menu. If a matching candidate is not found, it next attempts ambiguous matching (substring matching, etc.), We do not reset the completion for every input, even when the number of generated completions would be decreased not to hit the limit.
Because no menu is present in this case, the completion generation is attempted for
In some sense, the context is different: |
I thought it might be, I'm glad I filed this here instead :) Aha! OK, so what I am experiencing, seems inconsistent, but that is because of my lack of understanding/false expectation, and it is totally consistent, it is a mixture of two intentional behaviours:
And partly (because I use auto_menu after 1ms because I always want the menu)
Since this is not inconsistent behaviour, I think this can be closed now, I hope that's OK for you. The only way I can imagine, to maybe change this, would be for the command completion to still be generated when there are too many entries, so that they are filtered, but somehow not shown to the user... and that sounds exceedingly complex. Also, as you mention, there is a cost to this operation, so such a feature would likely demand an option to enable/disable it....seems like a lot of work, and I think the solution you outlined is fine. Also, regarding this and my other recent issues....Apologies for the 'pilot error'(s)! I have 57 tabs open in this browser window dedicated to ble.sh, and I'm trying to learn it all, but this is a very complex application! Thanks again for your help and especially patience!! |
I forgot to mention, but if you want to regenerate candidates by the TAB completion regardless of the presence of the menu, you can specify # blerc
ble-bind -m 'emacs' -f 'TAB' 'complete regenerate'
ble-bind -m 'emacs' -f 'C-i' 'complete regenerate'
ble-bind -m 'vi_imap' -f 'TAB' 'vi_imap/complete regenerate'
ble-bind -m 'vi_imap' -f 'C-i' 'vi_imap/complete regenerate' |
Hello again @akinomyoga I think maybe I have a hint about why the completions aren't generating properly for me. I noticed a similar behaviour, but maybe this is unrelated, so I will file a separate issue.
So for an example... I should mention that I used
rg hello_akinomyoga
to put something nice in my history which is auto-completed:I open a new terminal to demonstrate.
If I type "r", and hit tab (or use auto_menu), I see completions for variables:
Now I press "g" and this is refined (note it is a 'fuzzy' search, because 'rg' matches 'remaining' ... is that normal?):
Now if I press space, the menu disappears, and backspace to get just as above, and tab to open the menu again, now instead of variables, I see completion for commands (which seems more correct)....
So it seems like maybe it is not recognising the context somehow?
The text was updated successfully, but these errors were encountered: