[kitty & tmux & fzf] better way of changing some default bindings?

[ferdinandyb]

I use C-hjkl for seamless navigation between vim splits and tmux panes, which is obviously interfering with some of ble.sh's default maps. I used ble-bind -P to print all the current binding to a file and based on that added the snippet below to my init.sh.

Pressing C-z after finishing a multiline echo print a warning about multiline and using C-j, but doesn't actually execute:

Also, the snippet from #205 now prints ?????? at the bottom (sidenote: I've never actually seen a multiline status with any of the mode line settings, although it would be really welcome, since as a beginner with ble.sh I don't always really know where I am :))

Am I doing something wrong? Is there a more simple way to do this remapping? I don't care much about the functionalities lost by hklz, but obviously without j it's rather impossible to use ble.sh.

# because of tmux C-hjkl navigation unbind all of C-hjkl and bind
# original C-j to C-z
# I loose these of course
# ble-bind -m 'vi_imap' -f 'C-z' 'emacs-editing-mode'
# ble-bind -m 'vi_nmap' -f 'C-z' 'emacs-editing-mode'
# ble-bind -m 'vi_omap' -c 'C-z' 'fg'
# ble-bind -m 'vi_xmap' -c 'C-z' 'fg'

# ble-bind -m 'isearch' -f 'C-h' 'isearch/prev'
# ble-bind -m 'vi_imap' -f 'C-h' 'vi_imap/delete-region-or vi_imap/delete-backward-indent-or delete-backward-char'
# ble-bind -m 'vi_nmap' -f 'C-h' 'vi-command/backward-char wrap'
# ble-bind -m 'vi_omap' -f 'C-h' 'vi-command/backward-char wrap'
# ble-bind -m 'vi_xmap' -f 'C-h' 'vi-command/backward-char wrap'
# ble-bind -m 'vi_cmap' -f 'C-h' 'delete-region-or delete-backward-char'

# ble-bind -m 'isearch' -f 'C-j' 'isearch/accept-line'
# ble-bind -m 'nsearch' -f 'C-j' 'nsearch/accept-line'
# ble-bind -m 'vi_imap' -f 'C-j' 'accept-line'
# ble-bind -m 'vi_nmap' -f 'C-j' 'accept-line'
# ble-bind -m 'vi_omap' -f 'C-j' 'vi-command/forward-line'
# ble-bind -m 'vi_xmap' -f 'C-j' 'vi-command/forward-line'
# ble-bind -m 'vi_cmap' -f 'C-j' 'vi_cmap/accept'
# ble-bind -m 'auto_complete' -f 'C-j' 'auto_complete/accept-line'

# ble-bind -m 'vi_imap' -f 'C-k' 'kill-forward-line'
# ble-bind -m 'vi_cmap' -f 'C-k' 'kill-forward-line'

ble-bind -m 'vi_imap' -f 'C-l' 'clear-screen'
ble-bind -m 'vi_nmap' -f 'C-l' 'clear-screen'
ble-bind -m 'vi_cmap' -f 'C-l' 'redraw-line'
ble-bind -m 'isearch' -f 'C-h' ''
ble-bind -m 'vi_imap' -f 'C-h' ''
ble-bind -m 'vi_nmap' -f 'C-h' ''
ble-bind -m 'vi_omap' -f 'C-h' ''
ble-bind -m 'vi_xmap' -f 'C-h' ''
ble-bind -m 'vi_cmap' -f 'C-h' ''

ble-bind -m 'isearch' -f 'C-j' ''
ble-bind -m 'nsearch' -f 'C-j' ''
ble-bind -m 'vi_imap' -f 'C-j' ''
ble-bind -m 'vi_nmap' -f 'C-j' ''
ble-bind -m 'vi_omap' -f 'C-j' ''
ble-bind -m 'vi_xmap' -f 'C-j' ''
ble-bind -m 'vi_cmap' -f 'C-j' ''
ble-bind -m 'auto_complete' -f 'C-j' ''

ble-bind -m 'vi_imap' -f 'C-k' ''
ble-bind -m 'vi_cmap' -f 'C-k' ''

ble-bind -m 'vi_imap' -f 'C-l' ''
ble-bind -m 'vi_nmap' -f 'C-l' ''
ble-bind -m 'vi_cmap' -f 'C-l' ''

ble-bind -m 'isearch' -f 'C-z' 'isearch/accept-line'
ble-bind -m 'nsearch' -f 'C-z' 'nsearch/accept-line'
ble-bind -m 'vi_imap' -f 'C-z' 'accept-line'
ble-bind -m 'vi_nmap' -f 'C-z' 'accept-line'
ble-bind -m 'vi_omap' -f 'C-z' 'vi-command/forward-line'
ble-bind -m 'vi_xmap' -f 'C-z' 'vi-command/forward-line'
ble-bind -m 'vi_cmap' -f 'C-z' 'vi_cmap/accept'
ble-bind -m 'auto_complete' -f 'C-z' 'auto_complete/accept-line'

[akinomyoga]

I use C-hjkl for seamless navigation between vim splits and tmux panes, which is obviously interfering with some of ble.sh's default maps.

You do not need to unbind C-hjkl in ble.sh because these are prefiltered by tmux and ble.sh will never see them. For example, if you start [your terminal] -> [bash1] -> [tmux] -> [bash2] -> [vim], your key input goes in the following routes.

[Terminal]
 \_-> [bash1]
 \_-> [tmux]
         \_-> [bash2]
         \_-> [vim]

[bash1] and [tmux] read the PTY provided by your terminal, and [bash1] is stopping while [tmux] is running in the foreground. Similarly, [bash2] and [vim] read the PTY provided by tmux, and [bash2] is stopping while [vim] is running. Because both [tmux] and [vim] directly read the PTY from the terminal / terminal multiplexer, it cannot be interfered with ble.sh.

---

I used ble-bind -P to print all the current binding to a file and based on that added the snippet below to my init.sh.

Because you are using kitty, I think you should be able to use C-RET in most cases. Now I checked the behavior with kitty, and it turned out that the keyboard setup of kitty is not correctly enabled by some mistake and also a race condition with the terminal identification. I have fixed it in commit 14f3c81. Now you should be able to use C-RET which is by default used as a synonym of C-j in most keymaps of ble.sh.

The exception for C-RET is vi_imap where the Meta modifier is inherently confusing with ESC (as both are transmitted by the same byte 0x1b). For vi_imap, C-RET is by default used to insert a newline character, for which M-RET / C-M-m are used in other keymaps.

So, if you are fine with C-RET to run a command in the multiline mode of vi_imap, vi_nmap, and emacs, you can just configure C-RET for vi_imap. As for isearch, nsearch, and vi_cmap, because they do not have the multiline mode, the input C-j is always a synonym of RET / C-m so you can just use RET / C-m instead of C-j. Also, as for vi_nmap, vi_xmap, and vi_omap, the input C-j is always a synonym of j, so you can just use j instead of C-j. Finally, it should be fine with the following setting:

# blerc

ble-bind -m vi_imap -f C-RET accept-line

---

Pressing C-z after finishing a multiline echo print a warning about multiline and using C-j, but doesn't actually execute:

This is because you are in the Emacs editing mode but haven't configured C-z in the emacs keymap. If you still would like to use C-z to run the command, you should also add ble-bind -m emacs -f C-z accept-line.

---

Also, the snippet from #205 now prints ?????? at the bottom (sidenote: I've never actually seen a multiline status with any of the mode line settings, although it would be really welcome, since as a beginner with ble.sh I don't always really know where I am :))

It is designed for vim modes and does not support the emacs mode. Nevertheless, doesn't it work to replace ??????? in the snippet with some other string like -- EMACS --?

[ferdinandyb]

Oh, yes, you are absolutely right about no need to unbind anything! I changed my snippet to your single line example. After also updating ble.sh managed to execute multiline command with C-Enter in kitty. Unfortunately, this doesn't seem to work inside tmux. I'm not sure where the fault is, although I'm guessing tmux. (Tangential remark: I'd be happy to use standalone kitty without tmux if it had detachable sessions like tmux ...). Do you have any suggestions for a fix/workaround? Ctrl-Enter would be otherwise very intuitive, thank you!

On the note of the emacs mode: I was unaware I got there, but my intention is to be in vi mode. What did I do wrong to get there?

[akinomyoga]

Unfortunately, this doesn't seem to work inside tmux. I'm not sure where the fault is, although I'm guessing tmux.

I'd say it's the fault of kitty's design. This is a compatibility issue, so strictly speaking, it is not the fault of any projects, but just kitty cannot be combined with tmux for the keyboard protocol.

Actually, kitty is always doing something non-standard as a terminal emulator. Kitty's keyboard protocol is a typical example. Even though there is an existing protocol modifyOtherKeys established by xterm and supported by most of the modern terminals and terminal applications, kitty has invented another keyboard protocol with incompatible enabling/disabling sequences. In addition, kitty has stopped supporting modifyOtherKeys in kitty-0.24 just because the developer of kitty is not skilled enough in learning and implementing the correct behavior (kovidgoyal/kitty#4075). Now, just to compensate the developer's inability of learning the existing standard, kitty is requesting all the terminal applications to implement the kitty-specific protocol (kovidgoyal/kitty#3248 (comment)) even though there is an existing standard that works in all the other terminals with extended key inputs. Because of the reputation of kitty, some terminal applications (including ble.sh) support this kitty-specific protocol just to make it work in kitty, but no one can blame tmux or other applications for not supporting this only-in-kitty protocol. I think I can continue to write even more complaints on kitty for several pages, but let me stop here.

Do you have any suggestions for a fix/workaround? Ctrl-Enter would be otherwise very intuitive, thank you!

This time, I think I can add a workaround at ble.sh's side to pass-through the kitty-specific sequences of the keyboard protocol. This would make the keyboard controlling logic overcomplicated, so I feel the terminal application shouldn't support it normally. But I would still implement it in ble.sh no matter how it is dirty. That's the policy of ble.sh. I'll later implement it.

---

On the note of the emacs mode: I was unaware I got there, but my intention is to be in vi mode. What did I do wrong to get there?

In #209 (comment), I see you have keybindings of C-z to emcas-editing-mode in vi_[in]map, which is not the default of ble.sh. This means that you switch to the Emacs editing mode when you press C-z. Then, I found that these are actually set up by fzf key-bindings. Now I see the reason why you couldn't set up C-z for accept-line; Even if you set up the keybindings of C-z, these keybindings are overwritten by the fzf keybindings.

[ferdinandyb]

But I would still implement it in ble.sh no matter how it is dirty. That's the policy of ble.sh. I'll later implement it.

Your a gem :) I really hope terminals converge a bit, because choosing a terminal was not easy and with issues like these I'm not entirely happy with my choice either.

[ferdinandyb]

Current workaround is now adding

ble-bind -m 'isearch' -f 'C-z' 'isearch/accept-line'
ble-bind -m 'nsearch' -f 'C-z' 'nsearch/accept-line'
ble-bind -m 'vi_imap' -f 'C-z' 'accept-line'
ble-bind -m 'vi_nmap' -f 'C-z' 'accept-line'
ble-bind -m 'vi_omap' -f 'C-z' 'vi-command/forward-line'
ble-bind -m 'vi_xmap' -f 'C-z' 'vi-command/forward-line'
ble-bind -m 'vi_cmap' -f 'C-z' 'vi_cmap/accept'
ble-bind -m 'auto_complete' -f 'C-z' 'auto_complete/accept-line'

and commenting out the 'C-z' lines in fzf's key-binds, which currently works.

[akinomyoga]

This time, I think I can add a workaround at ble.sh's side to pass-through the kitty-specific sequences of the keyboard protocol. This would make the keyboard controlling logic overcomplicated, so I feel the terminal application shouldn't support it normally. But I would still implement it in ble.sh no matter how it is dirty. That's the policy of ble.sh. I'll later implement it.

I have implemented this in f66e0c1, but it is not enabled by default because there are some limitations. To turn on this feature, please use the following setting:

# blerc

bleopt term_modifyOtherKeys_passthrough_kitty_protocol=1

The limitations are explained in Manual §3.6.3 bleopt term_modifyOtherKeys_passthrough_kitty_protocol. Here are an explanation and backgrounds:

• In short, with the current version of tmux, you cannot turn on NumLock or CapsLock with this feature being enabled. There has been an issue in the tmux's implementation of interpreting the modifiers, so I submitted a PR to tmux (Parse input key modifiers as bitflags tmux/tmux#3259). I guess the fix will be in tmux-3.4. With the patched version of tmux, you can use term_modifyOtherKeys_passthrough_kitty_protocol=1 with NumLock and CapsLock without problems.
• Also, after detaching from tmux, in the same kitty session, terminal applications cannot be used outside tmux sessions.

Also, please set the following option in your ~/.tmux.conf:

# ~/.tmux.conf

set -g extended-keys on

# Or,
#set -g extended-keys always

[ferdinandyb]

works perfectly!

[akinomyoga]

• In short, with the current version of tmux, you cannot turn on NumLock or CapsLock with this feature being enabled. There has been an issue in the tmux's implementation of interpreting the modifiers, so I submitted a PR to tmux (tmux/tmux#3259). I guess the fix will be in tmux-3.4. With the patched version of tmux, you can use term_modifyOtherKeys_passthrough_kitty_protocol=1 with NumLock and CapsLock without problems.

PR tmux/tmux#3259 has been applied to tmux master in commit tmux/tmux@86dfbda. I'm not sure when would it be released, but if you like it, you can build the master version of tmux by yourself to make it work with kitty & ble.sh & CapsLock/NumLock.

Thank you again for reporting the issue! If there are no further related issues, you can close the issue.

[ferdinandyb]

thanks!