Skip to content
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

Closed
pallaswept opened this issue Jun 12, 2024 · 3 comments
Closed

Inconsistent behaviour from completion #459

pallaswept opened this issue Jun 12, 2024 · 3 comments

Comments

@pallaswept
Copy link

pallaswept commented Jun 12, 2024

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:

> rg hello_akinomyoga
remaining_sources : (variable) ''                                 | restricted : (variable) false                                     | ret : (array) [2 items]                                           | rex_raw_paramx : (variable) ''

Now I press "g" and this is refined (note it is a 'fuzzy' search, because 'rg' matches 'remaining' ... is that normal?):

> rg hello_akinomyoga
remaining_sources : (variable) ''

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)....

> rg
rg : (alias) rg --smart-case --no-ignore --hidden                                                                                     | rgb3toppm : (file) from /usr/bin

So it seems like maybe it is not recognising the context somehow?

@akinomyoga
Copy link
Owner

akinomyoga commented Jun 12, 2024

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.

@pallaswept
Copy link
Author

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!!

@akinomyoga
Copy link
Owner

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'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants