Kitty's terminal protocol & complete_menu_complete_opts

[gvlassis]

Hello!

1. I am using the latest Kitty+ble.sh, and the following keymap does not work: ble-bind -f "TAB" "complete enter_menu". However, if I change the keymap to ble-bind -f "C-i" "complete enter_menu", it works just fine. I thought that Kitty's terminal protocol was supported, alongside ModifyOtherKeys. Is this not the case?

2. When you enter menu-complete and you change your selection in the menu, the current selection is mirrored in the command-line (with color region_insert). Is there any way to disable this? I tried the option: complete_menu_complete_opts=hidden, and it seems to do the job, but the cursor is moved to the begining of the word in the command-line.

    GNU bash, version 5.2.21(1)-release (aarch64-apple-darwin23.0.0)
    ble.sh, version 0.4.0-devel4+70a325f (noarch) [git 2.44.0, GNU Make 4.3, GNU Awk 5.3.0, API 4.0, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
    atuin, version 18.1.0 (/Users/gvlassis/.local/bin/atuin)
    locale: LANG=en_US.UTF-8
    terminal: TERM=xterm-kitty wcwidth=15.0-west/15.1-2+ri, kitty:0 (1;4000;34)
   

[akinomyoga]

1. I am using the latest Kitty+ble.sh, and the following keymap does not work: ble-bind -f "TAB" "complete enter_menu". However, if I change the keymap to ble-bind -f "C-i" "complete enter_menu", it works just fine. I thought that Kitty's terminal protocol was supported, alongside ModifyOtherKeys. Is this not the case?

Thanks. I confirmed the reported behavior. It turned out that the behavior is the same also in Xterm with modifyOtherKeys.

I've checked the behavior of the terminals. I have to admit that I haven't carefully thought about the actual behavior of the keyboard protocols; the behavior I have been unconsciously expecting from the keyboard protocols seems to be different from the actual behavior.

Keyboard protocol	Key	Sequence
conventional	TAB	\x09
conventional	C-i	\x09
modifyOtherKeys / kitty's	TAB	\x09
modifyOtherKeys / kitty's	C-i	\x1b[27;5;105~ or \x1b[105;5u
(my naive expectation)	TAB	\x1b[27;1;9~ or \x1b[9u
(my naive expectation)	C-i	\x1b[27;5;105~ or \x1b[105;5u

The advanced keyboard protocols are expected to produce different sequences for TAB and C-i. In the actual terminal protocols, this turned out to be achieved by changing the sequence of C-i while keeping the sequence of TAB.

Here, there is a subtlety. For an arbitrary terminal, there is no way to detect whether the advanced keyboard protocol is turned on. Then, when we receive \x09, we cannot tell whether it was sent by the conventional protocol or an advanced protocol. Thus, we cannot tell whether it is actually TAB or C-i. Even if we know that the current terminal supports an advanced keyboard protocol, there is no robust way to know the protocol that sent \x09 because ble.sh dynamically switches the keyboard protocol for execution of the user commands and other external Bash plugins. Then, \x09 sent by the terminals supporting an advanced keyboard protocol is inherently ambiguous in the use pattern of ble.sh.

Currently, ble.sh always translates \x09 to C-i because it is consistent with the other keys C-a..C-z in the conventional terminal protocol. Maybe I'll have to introduce some exceptions in the future, but I wouldn't like to introduce the change for now because it might break the existing users' setup and also such an exception only has an effect when the terminal supports an advanced protocol and the user explicitly assigns different widgets to two keys.

I'm now thinking of requiring the user to explicitly configure the mapping from \x09 to TAB (I'll later add descriptions on the wiki page). Could you update ble.sh to the latest master by running ble-update and put the following setting in your ~/.bashrc?

# ~/.blerc
ble-bind -k TAB TAB

The above setting didn't actually work in the previous version of ble.sh because the TAB (which is equivalent to \x09 in ble.sh's internal representation) produced by the -k mapping was still subject to the conversion to C-i. I changed this behavior in commit cbf87fd so that the conversion is not applied to the key produced by the -k mapping.

2. I tried the option: complete_menu_complete_opts=hidden,

I guess what you have tried has been complete_menu_complete_opts=. If you set complete_menu_complete_opts=hidden, I think the selected item is directly reflected in the command line because the menu is hidden. (Or if you haven't tried complete_menu_complete_opts=, it is probably what you should try.)

and it seems to do the job, but the cursor is moved to the begining of the word in the command-line.

Thanks for the report. I agree that it is natural to keep the cursor at the original position. I fixed it in commit 341179d.

[gvlassis]

I can confirm that:

# ~/.blerc
ble-bind -k TAB TAB
ble-bind -m "emacs" -s "TAB" "    "

, works as expected!

I also confirm that complete_menu_complete_opts="" now has the expected behavious (cursor not moving).

Unfortunately, it seems like this update broke ESC on Kitty. With the following config:

# ~/.blerc
ble-bind -s "ESC" "X"
ble-bind -s "C-[" "X"

, I have an empty square appearing every time I press ESC. I also attach a screenshot:

[akinomyoga]

Unfortunately, it seems like this update broke ESC on Kitty. With the following config:

@gvlassis @10b14224cc @lokxii Thanks for the report, and sorry for the delay. I've pushed a fix 365101c to the master. Could you update ble.sh by ble-update and see the behavior?

[lokxii]

Just tested. Pressing esc does go to normal mode. Thx!

[10b14224cc]

Now goes to normal mode in kitty correctly for me as well.

But why the changelog is in chinese?

[akinomyoga]

Thank you!

[akinomyoga]

But why the changelog is in chinese?

It's not Chinese. It's Japanese, and I use Japanese because that is my native language.

Also, it's not ChangeLog, but it's a development log, which I work with. ChangeLog, which the users might look, is written in English (except for the first few years).

[akinomyoga]

I think the original issues were solved, and also the additional issue in #445 (comment) was also fixed as reported by @lokxii and @10b14224cc, so let me close the issue. Thank you!

[gvlassis]

So sorry for not replying for so long! Life happened 🥲. Yes, I confirm that the issues were solved.

[akinomyoga]

No problem!