[fzf 0.70.0] fzf cannot perform fuzzy-find-completion when ble.sh is sourced under xterm

[hiroshi-ya]

$ ble summary
GNU bash, version 5.3.9(1)-release (x86_64-pc-linux-gnu) [Arch Linux]
ble.sh, version 0.4.0-nightly+4706cb2 (noarch) [git 2.53.0, GNU Make 4.3, GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
fzf key-bindings, (hash:719288b065965d8fb3248ad31d3b4ab4bf9d3808, 3414 bytes) (noarch) (integration: off)
WARNING: fzf integration "integration/fzf-key-bindings" is not activated.
fzf completion, (hash:719288b065965d8fb3248ad31d3b4ab4bf9d3808, 3414 bytes) (noarch) (integration: on)
starship, version 1.24.2+33f7077fb (rustc 1.93.0 (254b59607 2026-01-19) (Arch Linux rust 1:1.93.0-1), 2026-02-14 19:43:02 +00:00)
zoxide, version 0.9.9 (/usr/sbin/zoxide) (integration: off)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=16.0-west/16.0-2+ri, wt:0 (0;10;1)
options: +histappend +inherit_errexit +login_shell

fzf cannot perform fuzzy-find-completion when ble.sh is sourced and running under my WSL (Arch Linux) setup (which defaults to xterm-256color). For example, if I want to fuzzy find a file for vim:

$ vim ** # and press TAB

The list view will show up, and I can browse any option provided. However, after hitting enter, the terminal emulator will complain:

unbound keyseq: dsr0

and no auto-completion is done.

I tried to log the key strokes:

$ ble/debug/keylog#start
# vim ** # deleted using C-u
$ ble/debug/keylog#end
===== bytes =====
118 105 109 32 42 42 9 192 155 91 48 110
 21 192 155 91 50 48 48 126 98 108 101 4
7 100 101 98 117 103 47 107 101 121 108
111 103 35 101 110 100 192 155 91 50 48
49 126 13

===== chars =====
v i m SP * * TAB ESC [ 0 n NAK ESC [ 2 0
 0 ~ b l e / d e b u g / k e y l o g # e
 n d ESC [ 2 0 1 ~ RET

===== keys =====
v ac_enter i m SP SP ac_enter * * * C-i
dsr0 C-u paste_begin C-m

Doing a simple search for dsr0:
lib/init-cmap.sh

2025-05-04 Add a new key "dsr0" for "ESC [ 0 n

But I have no idea why dsr0 is an issue for xterm.

On my Arch Linux machine, fzf works fine with ble.sh under alacritty, but when using xterm, it has the same dsr0 issue. I can just use alacritty on my Linux machine, but I don't think WSL allows you to change the terminal running under the hood - I tried using both Windows and WSL alacritty, and they both have the same issue.

I tried running fzf with ble.sh disabled, and fzf can then perform auto-completion just fine. Not exactly sure if it's a fzf problem or ble.sh problem or xterm problem :(

[akinomyoga]

I haven't looked into this in detail, but Fzf and Zoxide might be interfering. Both try to exploit the DSR(0) response from the terminal (which is a response to the DSR(5) request).

• Add fixes to Bash integration ajeetdsouza/zoxide#1048
• bash: set keybinding right before printing special character junegunn/fzf#4377
• zoxide <Space><Tab> completion does not work with ble #580

My naive guess offhand is that Alacritty hasn't yet supported the response to the DSR(5) request; if that's true, the exception is rather Alacritty because most terminals support the response. However, I haven't yet actually examined that my guess is correct.

[akinomyoga]

@hiroshi-ya If you disable the Zoxide integration from your shell settings, does the situation change?

[hiroshi-ya]

@hiroshi-ya If you disable the Zoxide integration from your shell settings, does the situation change?

Unfortunately, no, the issue persists after disabling zoxide (both in WSL and in real Linux xterm):

$ ble summary
GNU bash, version 5.3.9(1)-release (x86_64-pc-linux-gnu) [Arch Linux]
ble.sh, version 0.4.0-nightly+4706cb2 (noarch) [git 2.53.0, GNU Make 4.3, GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
fzf key-bindings, (hash:9f1e016f913d776afb08df50be10ac251c30ff1f, 3415 bytes) (noarch) (integration: off)
WARNING: fzf integration "integration/fzf-key-bindings" is not activated.
fzf completion, (hash:9f1e016f913d776afb08df50be10ac251c30ff1f, 3415 bytes) (noarch) (integration: on)
starship, version 1.24.2+33f7077fb (rustc 1.93.0 (254b59607 2026-01-19) (Arch Linux rust 1:1.93.0-1), 2026-02-14 19:43:02 +00:00)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=16.0-west/16.0-2+ri, wt:0 (0;10;1)
options: +histappend +inherit_errexit +login_shell

Besides, I have never faced any issue using zoxide. Both z foo and zi foo seem to work as intended.

[hiroshi-ya]

I'm not exactly sure what I did, but it seems that ble.sh and fzf can no longer co-work within alacritty, either

[greg17477]

I can confirm this issue. Tested on Kitty and Gnome terminal.

❯ ble summary
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu) [Ubuntu 22.04.5 LTS]
ble.sh, version 0.4.0-devel4+b99cadb (noarch) [git 2.34.1, GNU Make 4.3, GNU Awk 5.1.0, API: 3.0 (GNU MPFR 4.1.0, GNU MP 6.2.1)]
bash-completion, version 2.17.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
fzf key-bindings, (hash:d0c50518b5502a7a9fcf7019c183247808da379b, 157 bytes) (noarch) (integration: on)
fzf completion, (hash:d0c50518b5502a7a9fcf7019c183247808da379b, 157 bytes) (noarch) (integration: on)
starship, version 1.24.2-master+33f7077 (rustc 1.92.0 (ded5c06cf 2025-12-08), 2025-12-30 19:14:09 +00:00)
zoxide, version 0.9.8 (~/.local/bin/zoxide) (integration: off)
locale: LANG=en_US.UTF-8 LC_ADDRESS=de_DE.UTF-8 LC_IDENTIFICATION=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_NAME=de_DE.UTF-8 LC_NUMERIC=de_DE.UTF-8 LC_PAPER=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_TIME=de_DE.UTF-8
terminal: TERM=xterm-kitty wcwidth=14.0-west/16.0-2+ri, tmux:0 (84;0;0), kitty:0 (1;4000;46)
options: +ignoreeof +onecmd +autocd +cdspell +direxpand +dirspell +extglob +histappend -hostcomplete +inherit_errexit +login_shell

[markaacosta]

I believe I'm having the same issue, I also get:

unbound keyseq: dsr0

here's my attempt:

# get a clean shell
bash --norc
# manually source `ble.sh` and the `fzf-completion` integration
bash-5.3$ source ~/.local/share/blesh/ble.sh
bash-5.3$ ble-import -d integration/fzf-completion
# try and use fzf `**` tab completion                                                                                                       
bash-5.3$ readlink -f **

with latest blesh and fzf, and a clean shell environment, fzf-completion fails in my terminal kitty. I tested in foot and Console the same way, it failed in those too

more info:

bash-5.3$ ble summary                                                                                                                                    23:16:37
GNU bash, version 5.3.9(1)-release (x86_64-pc-linux-gnu) [NixOS 26.05 (Yarara)]
ble.sh, version 0.4.0-devel4+b99cadb4 (noarch) [git 2.53.0, GNU Make 4.4.1, GNU Awk 5.3.2, API 4.0, PMA Avon 8-g1]
fzf completion, (hash:256556325dac5944e55ffa9dabf980c159304011, 21759 bytes) (noarch) (integration: on)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=16.0-west/16.0-2+ri, kitty:0 (1;4000;45)
options: -emacs +vi +inherit_errexit

I'm happy to provide more info, just let me know

[madeupandprobablydoesnotexist]

I'm having this issue with just ble.sh and fzf, terminal kitty

[akinomyoga]

I couldn't reproduce the problem in a clean environment in any terminal, but now I have reproduced the problem with the latest version of fzf 0.70.0 (eacef5ea). The problem doesn't happen with fzf 0.57.0 (Fedora) and fzf 0.66.1 (c1b259c0).

OK, junegunn/fzf#4684 broke this.

[hiroshi-ya]

I couldn't reproduce the problem in a clean environment in any terminal, but now I have reproduced the problem with the latest version of fzf 0.70.0 (eacef5ea). The problem doesn't happen with fzf 0.57.0 (Fedora) and fzf 0.66.1 (c1b259c0).

OK, junegunn/fzf#4684 broke this.

Thank you for taking the time to dig around. Yes, looks like that commit broke this. Downgraded fzf to an older release 0.68.0 (b908f7a0) and the issue is gone.

Should I open an issue on fzf then? Or should I expect ble.sh to handle the compatibility issue?

[akinomyoga]

I have to think about the workaround. If I conclude that ble.sh cannot work around this issue purely at the ble.sh side, I'd rather request Fzf to include detection of ble.sh and integration so that we do not need the extra integration code at all.

[madeupandprobablydoesnotexist]

I couldn't reproduce the problem in a clean environment in any terminal, but now I have reproduced the problem with the latest version of fzf 0.70.0 (eacef5ea). The problem doesn't happen with fzf 0.57.0 (Fedora) and fzf 0.66.1 (c1b259c0).

OK, junegunn/fzf#4684 broke this.

Thank you for diagnosing! Downgraded fzf and it works fine now.

[pallaswept]

I will give a "me too" since nobody has reported it on konsole yet. I see you're already on top of it, thanks everyone.

Here's an easy temporary workaround for others in the meantime if they need to stick with the 0.70 release of fzf:

sudo sed -i -E 's/builtin printf/printf/' /usr/share/fzf/shell/completion.bash

This will "break" the system's installation of fzf, by reverting that fix for gnu coreutils on macos, so you will want to reinstall fzf over the top of this to revert the change, when everything is fixed.