menu_complete key binds disappear randomly

[quantumfrost]

$ ble summary

GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu) [Ubuntu 24.04.2 LTS]
ble.sh, version 0.4.0-devel4+4338bbf (noarch) [git 2.43.0, GNU Make 4.3, GNU Awk 5.3.1, API 4.0, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
bash-completion, version 2.16.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
fzf key-bindings, (hash:8b0ef76c65a55e74cde19e726bf076349e680fe3, 5635 bytes) (noarch) (integration: on)
fzf completion, (hash:d1fc57b95ccaf5823368af60b840010a8e4ca85d, 18397 bytes) (noarch) (integration: on)
zoxide, version 0.9.7 (/home/linuxbrew/.linuxbrew/bin/zoxide)
atuin, version 18.4.0 (/home/linuxbrew/.linuxbrew/bin/atuin)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=15.0-west/16.0-2+ri, unknown:- (61;7600;1)
options: +extglob +histappend -hostcomplete +inherit_errexit

Sometimes the menu_complete keybinds seem to disappear and cannot be edited or viewed. Other times they work fine. I've included screenshots.

Working fine:

Gone:

Other keybinds, like auto_complete are still listed if I just run ble-bind, but it doesn't show any menu_copmlete entries.

[akinomyoga]

Your observation is correct. These behaviors are expected.

menu_complete key binds disappear randomly

It might be confusing to the user, but it's not random. Keymaps are initialized by lazy loading, which means that they will not be initialized until they are actually used. In the case of the menu_complete keymap, the menu_complete keymap is initialized on the first use of the menu-complete feature.

Sometimes the menu_complete keybinds seem to disappear and cannot be edited or viewed.

It can actually be edited, but it just cannot be viewed until the keymap is initialized. The user keybindings specified before the initialization of the keymap are recorded elsewhere (e.g. you can run cat "$_ble_base_run/$$.bind.delay.menu_complete" to see the records for the menu_complete keymap), and they will be processed when the keymap is initialized.

Other keybinds, like auto_complete are still listed if I just run ble-bind, but it doesn't show any menu_copmlete entries.

The reason that you always see the content of the auto_complete keymap is most probably because auto-complete is triggered while you input ble-bind to examine the auto_complete keymap.

If you want to manually initialize the keymap, you can run the following command:

$ ble/decode/keymap#load <keymap_name>

where <keymap_name> should be replaced by the actual name of the keymap that you want to initialize. In the case of the menu_complete keymap, you can run the following command:

$ ble/decode/keymap#load menu_complete

After this, you should be able to see the contents of the keymap by ble-bind -m menu_complete.

Note: The function ble/decode/keymap#load is an internal API, so the name might be changed in the future, though I currently don't have any plan to change it.

[quantumfrost]

Thanks a lot. You are right, they can still be edited, and they appear after I use menu completion.

I also have another issue with menu complete. I use this project to enable completion for aliases: https://github.com/cykerway/complete-alias

But the first time I use an alias with blesh enabled, I get this issue:

As you can see, the completion is also adding the option description to the command.

Once I run completion for the original command once (in this case it's chezmoi), and run the alias again, I get the correct behavior:

Without blesh, I don't have this issue (because there's no menu completion anyway). I understand if this cannot be fixed because I'm using that other project.

I think ble.sh is a much more complex project than it seems at first! It would be great if the documentation was organized a bit better, according to the common tasks that people might want to accomplish.

[akinomyoga]

I also have another issue with menu complete. I use this project to enable completion for aliases:
https://github.com/cykerway/complete-alias

Could you turn off this setting and instead set shopt -s progcomp_alias when you enable ble.sh? The feature that cykerway/complete-alias attempts to provide is already implemented in ble.sh in an even better way. One thing to be noted is that you need to explicitly turn it on by setting shopt -s progcomp_alias.

Actually, as you notice by the option shopt progcomp_alias, Bash also tries to implement it, but the implementation is broken. You can find a full story at Ref. [1]. You can also find related discussions in Refs. [2, 3].

• [1] adding t alias conditianal completion ohmybash/oh-my-bash#380 (comment)
• [2] progcomp_alias bash option does not work due to 'complete -F _completion_loader -D' scop/bash-completion#383
• [3] adding an alias completion helper scop/bash-completion#521

But the first time I use an alias with blesh enabled, I get this issue:

This is caused when the external completion setting includes the description directly in the completion candidates it generates. I don't like this hack because we cannot tell a priori whether the candidates generated by the external completion settings would include description in the completions itself. ble.sh currently detects known completion settings (that include the descriptions in their results) and process their results according to the respective implementations.

Once I run completion for the original command once (in this case it's chezmoi), and run the alias again, I get the correct behavior:

I think the chezmoi completion is generated by the cobra framework, which is covered by ble.sh. ble.sh's detection of cobra is found here and the workaround codes are found here, which were originally introduced after #183.

Just the combination of cykerway/complete-alias and chezmoi is not covered by ble.sh. I'm not sure if we would need to add the detection codes for the situation with cykerway/complete-alias and implement workarounds for it, because cykerway/complete-alias is inferior to ble.sh's implementation of shopt -s progcomp_alias and thus is unnecessary with ble.sh.

It would be great if the documentation was organized a bit better, according to the common tasks that people might want to accomplish.

Thanks for the suggestion, but could you explain in more detail what you are specifically thinking about? How would you think we can reorganize the documentation to help people in the present case?

[akinomyoga]

I'm thinking of whether it would make sense and wouldn't cause conflicts to forcibly initialize the keymap when the user attempts to print the contents of the keymap explicitly specified as ble-bind -m ....

As for cykerway/complete_alias, it seems to internally use bash-completion's _command_offset. Then, the _command_offset internally uses __load_completion (with bash-completion < 2.12) or _comp_load (with bash-completion >= 2.12). The use of __load_completion and _comp_load is more common than cykerway/complete_alias, and they can be used in cases where combining it with ble.sh makes sense. Then, maybe I can consider hooking into _comp_load and __load_completion from bash-completion.

[quantumfrost]

Could you turn off this setting and instead set shopt -s progcomp_alias when you enable ble.sh? The feature that cykerway/complete-alias attempts to provide is already implemented in ble.sh in an even better way. One thing to be noted is that you need to explicitly turn it on by setting shopt -s progcomp_alias.

Thanks, I didn't know that blesh already has this functionality, in which case I do not need the complete_alias project. I'm having some trouble with the blesh alias autocomplete, however. I have ls as an alias for eza, but blesh actually shows me autocomplete for ls:

This is caused when the external completion setting includes the description directly in the completion candidates it generates. I don't like this hack because we cannot tell a priori whether the candidates generated by the external completion settings would include description in the completions itself.

Thanks, I thought that must be the case, because I noticed chezmoi displayed descriptions even without blesh. But now that I have disabled complete_alias and am using shopt -s progcomp_alias, cm completion is working correctly. I think there is no need to support other projects if blesh has a better implementation.

Thanks for the suggestion, but could you explain in more detail what you are specifically thinking about? How would you think we can reorganize the documentation to help people in the present case?

That was more of a general comment than specific to this issue. If I have some concrete suggestions, I will take note of them and let you know after I'm done setting up blesh. For one thing, I think you should include a general overview of the features at the top of the main README.md. I installed blesh because it was recommended by atuin, and I didn't even know that it had so many great features.

I'm thinking of whether it would make sense and wouldn't cause conflicts to forcibly initialize the keymap when the user attempts to print the contents of the keymap explicitly specified as ble-bind -m ....

That might be a good idea, because it was confusing as a user. But I don't really know about the internals of blesh so I don't know if there can be any conflicts

[akinomyoga]

Sorry for the delay.

I'm thinking of whether it would make sense and wouldn't cause conflicts to forcibly initialize the keymap when the user attempts to print the contents of the keymap explicitly specified as ble-bind -m ....

That might be a good idea, because it was confusing as a user. But I don't really know about the internals of blesh so I don't know if there can be any conflicts

In commit 66e450d, I changed to initialize the keymap on request by ble-bind -m keymap.

---

Thanks, I didn't know that blesh already has this functionality, in which case I do not need the complete_alias project. I'm having some trouble with the blesh alias autocomplete, however. I have ls as an alias for eza, but blesh actually shows me autocomplete for ls:

This is related to which completion setting we should use for alias a='b ...' when completion settings exist for both a and b.

• I've been assuming that if the completion setting for a exists, it means that the completion setting offers more precise completion for the alias than the one for b offers. For this reason, ble.sh uses the completion setting for a.
• In your case, the situation is the opposite, which I haven't thought about it until your reply. In your case, you try to replace the existing command ls with another tool eza. The problem is that even if you don't use the ls command for ls, the completion setting for the ls command still exists, which is picked up by ble.sh.

In general, It is difficult for ble.sh to know whether the completion setting for a that ble.sh found is for the command that the user overwrote, or whether it is for the alias that the user defined. I think it is reasonable to ask the user to remove the completion setting that the user overwrites.

E.g., you can remove the completion setting for the old ls command by complete -r ls. If you use bash-completion and have a dedicated completion setting file at /usr/share/bash-completion/completions/ls or ~/.local/share/bash-completion/completions/ls, you need to remove that file. Or if it is difficult, the user needs to explicitly overwrite the completion setting for ls with the one for eza.