Closed pallaswept closed 3 weeks ago
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,
That is unrelated. As I already mentioned, the absence of the rg
completion is reproduced in my environment, and it is just because the man page format of rg
is incompatible with the formats ble.sh assumes.
You've noticed that the cache for the rg
completion is not created, but it doesn't mean the rg
completion isn't triggered. The cache file is not created when no options are found on the man page. In addition, I already have an initial implementation of the analysis of the rg
man page (edit: in my local branch), and it's now working except that some option descriptions are still not correctly extracted.
I open a new terminal to demonstrate. If I type "r", and hit tab (or use auto_menu), I see completions for variables:
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 bleopt complete_limit
or bleopt complete_limit_auto_menu
(in the case of auto_menu
), the generation of the command names will be canceled. By default, there is no limit for the tab completion, while the limit is set to a small number 100
for auto_menu
. This is because auto_menu
is always triggered in the background so we want to avoid consuming much CPU in the context where it generates too many candidates. If you would like to get a consistent completion results for both the tab completion and auto_menu
, you can remove the limit for auto_menu
by setting an empty string to bleopt complete_limit_auto_menu
, or you can set a larger value.
Now I press "g" and this is refined (note it is a 'fuzzy' search, because 'rg' matches 'remaining' ... is that normal?):
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.
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)....
Because no menu is present in this case, the completion generation is attempted for rg
. The number of candidates starting with rg
doesn't hit the limit. Then, all the results are shown . The reason that no variables are generated should be that there are no variables starting with rg
in your case.
So it seems like maybe it is not recognising the context somehow?
In some sense, the context is different: r
vs rg
, or presence vs absence of the menu.
That is unrelated.
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:
if the number of generated command names is larger than the limit set by bleopt complete_limit or bleopt complete_limit_auto_menu (in the case of auto_menu), the generation of the command names will be canceled
When a menu is already open, the completion is performed within the candidates shown in the menu
And partly (because I use auto_menu after 1ms because I always want the menu)
the limit is set to a small number 100 for auto_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 regenerate
option to the complete
widget.
# 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?