Ctrl-key no longer work in fzf

[tessus]

GNU bash, version 5.2.26(1)-release (x86_64-apple-darwin23.2.0)
ble.sh, version 0.4.0-devel4+fcbf1ed (noarch) [git 2.45.2, GNU Make 3.81, GNU Awk 5.3.0, API 4.0, PMA Avon 8-g1]
bash-completion, version 2.14.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
fzf key-bindings, (hash:2da32cbab672fc962b4c56c6a052a6bf47ef2c12, 5618 bytes) (noarch) (integration: on)
fzf completion, (hash:a68dac96ed6e60c7dc412b44705f6a343089146f, 16216 bytes) (noarch) (integration: on)
starship, version 1.19.0 (rustc 1.78.0 (9b00956e5 2024-04-29),stable-x86_64-apple-darwin 2024-05-18 01:22:19 -04:00)
zoxide, version 0.9.4 (/Users/tessus/.cargo/bin/zoxide)
atuin, version 18.4.0-beta.2 (/Users/tessus/.cargo/bin/atuin)
locale: LANG=en_US.utf-8 LC_ALL=en_US.utf-8 LC_CTYPE=en_US.utf-8 LC_TERMINAL=iTerm2 LC_TERMINAL_VERSION=3.5.3
terminal: TERM=xterm-256color wcwidth=15.0-west/15.1-2+ri, iTerm2:3.5.3 (41;2500;0)

I am using my own fzf git integration and you gave me the solution to make it work with ble:

if [[ ${BLE_VERSION-} ]]; then
  function ble/widget/fzf-git {
    ble/widget/insert-string "$(fzf_$1)"
    ble/textarea#invalidate
  }
  ble-bind -f 'C-g C-f' 'fzf-git gf'
  ble-bind -f 'C-g C-b' 'fzf-git gb'
  ble-bind -f 'C-g C-t' 'fzf-git gt'
  ble-bind -f 'C-g C-h' 'fzf-git gh'
  ble-bind -f 'C-g C-r' 'fzf-git gr'
  ble-bind -f 'C-g C-l' 'fzf-git gl'
  ble-bind -m auto_complete -f 'C-g' -
else
  bind '"\er": redraw-current-line'
  bind '"\C-g\C-f": "$(fzf_gf)\e\C-e\er"'
  bind '"\C-g\C-b": "$(fzf_gb)\e\C-e\er"'
  bind '"\C-g\C-t": "$(fzf_gt)\e\C-e\er"'
  bind '"\C-g\C-h": "$(fzf_gh)\e\C-e\er"'
  bind '"\C-g\C-r": "$(fzf_gr)\e\C-e\er"'
  bind '"\C-g\C-l": "$(fzf_gl)\e\C-e\er"'
fi

The full file is here: fzf_git.sh.txt

However, when I now press C-g C-h I can't use any Ctrl-key key combinations in fzf anymore. Luckily I can still use Esc to quit fzf.

Here is a video:

(First I use C-g C-h to invoke fzf. Then I press Ctrl-S. Nothing happens. Then I press Ctrl-S again and 2 times Ctrl-C.)

https://github.com/user-attachments/assets/0284a08a-25a5-4449-9e9a-7d725e3571b4

[akinomyoga]

Hmm, OK. Could you update the function ble/widget/fzf-git with the following definition?

function ble/widget/fzf-git {
  ble/term/leave-for-widget
  local insert=$(_fzf_git_$1)
  ble/term/enter-for-widget
  ble/widget/insert-string "$insert"
  ble/textarea#invalidate
}

I'll also update contrib/integration/fzf-git.bash later.

I think the reason that the problem didn't happen before was just because iTerm2 was not recognized. I think it was treated as a VTE-based terminal instead. In ble.sh, the VTE-based terminals are blacklisted for advanced keyboard protocols, so the advanced keyboard protocols were not enabled. I recently added da6e71db89e6f4a2be4f8c2c610ef4b418b9725a to detect iTerm2, so ble.sh now enables modifyOtherKeys in iTerm2, and then fzf was confused by modifyOtherKeys. I forgot to adjust the terminal state when calling the command fzf in ble/widget/fzf-git.

[tessus]

This worked! Thank you.

In my case it is local insert=$(fzf_$1) though... I think this issue can be closed. Please feel free to do so.

[akinomyoga]

Thank you for checking the behavior! I applied fixes also to contrib/integration/fzf-git.bash in commit https://github.com/akinomyoga/blesh-contrib/commit/3019780ed33a4bc352ed3ab05e9508a6e7386bc7.

[tessus]

Thank you for the quick reply.

Unfortunatelty after the last update to ble my arrow-up no longer works (it is supposed to invoke atuin) and when starting the shell, I can see the text "loading history...." (under the current prompt) for 500ms and then it disappears. It also seems sluggish and at one point an alias didn't work.

I have reverted back to fcbf1ed.

[akinomyoga]

Hmm, OK. Thank you for the report. I could reproduce the problem. The problem seems to happen when Atuin is loaded before ble.sh. I'll check it.

[tessus]

I am not sure how this is possible. I source ble at the beginning of my .bashrc, then there is a bunch of other stuff, and at the very end atuin is initialized.

[akinomyoga]

I pushed a fix bb2dae6e6bdc15cb853e463021268087b45c54b9.

This was a serious regression caused by 51e762fe1c82e3ecb02940462164860f2765cb32, where I changed the initialization position of the variable for the Bash version detection (_ble_bash). I put builtin unset -v _ble_bash in a wrong place, which caused the missing Bash version information. Then, the entire ble.sh started to work in the "Bash 3.0" mode and caused incompatibility with the behavior difference between the Bash versions.

[ Honestly, I was surprised that ble.sh seemed to work mostly fine in Bash 5.3 (I'm currently testing ble.sh under the unreleased next Bash version 5.3) with its "Bash 3.0" mode, although I've never tried that until now. I thought it would be broken more terribly. ]

[tessus]

Thanks. The fix worked!

[akinomyoga]

Thank you for the confirmation!