Does not redraw on insert by keymap

[sharpchen]

$ ble summary

GNU bash, version 5.3.3(1)-release (x86_64-pc-linux-gnu) [NixOS 25.11 (Xantusia)]
ble.sh, version 0.4.0-devel3+1a5c451c (noarch) [git 2.39.0, GNU Make 4.3, GNU Awk 5.1.1, API: 3.1 (GNU MPFR 4.1.0-p13, GNU MP 6.2.1)]
bash-completion, version 2.16.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
fzf key-bindings, (hash:50edecefb265ecdc349c0c6c39cb5d80887eff88, 5940 bytes) (noarch) (integration: on)
fzf completion, (hash:63d9d7dbd5247f1b0a39e808af8cbce41ad21715, 5497 bytes) (noarch) (integration: on)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=15.0-west/15.0-2+ri, wezterm:20220408 (1;277;0)

I have the following keymaps in .inputrc which would basically surround something with $()
blesh does not redraw when the keymap is triggered, but redraw after whatever operation that can trigger the redraw.

# .inputrc
set keymap vi-command
" z": "I$(\eA)\e"
" Z": "i$(\eA)\e"

To reproduce simply type <space>z:

foo.mov

[akinomyoga]

I confirmed the behavior.

This is not a problem with redrawing, but the last byte \e isn't actually processed and pending in the input stream until the next character appears. This is related to the ambiguity of \e: it can meanESC (or equivalently C-[) but can also be an introducer of the escape sequences that are used to represent various types of special keys such as up (\e[A), home (\e[1~), and delete (\e[3~). The problem doesn't happen with the actual user input because ble.sh uses the timing information to distinguish the two cases. In the case of string macros (set by "...": "...\e"), something related to timing detection or the distinction of the two types of \e is probably broken. I'll investigate it.