`Processing Input...` interaction blocker

[micimize]

$ ble summary

GNU bash, version 5.2.37(1)-release (x86_64-redhat-linux-gnu) [Aurora (Version: 42.20250831.1 / FROM Fedora Kinoite 42)]
ble.sh, version 0.4.0-devel4+8060b7ad (noarch) [git 2.51.0, GNU Make 4.4.1, GNU Awk 5.3.1, API 4.0, PMA Avon 8-g1, (GNU MPFR 4.2.2, GNU MP 6.3.0)]
bash-completion, version 2.16.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
fzf key-bindings, (hash:50edecefb265ecdc349c0c6c39cb5d80887eff88, 5940 bytes) (noarch) (integration: on)
fzf completion, (hash:965bdb40dadd1a88d840c51304197e297b7af8a2, 20443 bytes) (noarch) (integration: on)
starship, version 1.23.0 (rustc 1.86.0 (05f9846f8 2025-03-31) (Homebrew), 2025-04-27 15:52:14 +00:00)
locale: LANG=en_US.UTF-8
terminal: TERM=screen-256color wcwidth=16.0-west/16.0-2+ri, tmux:0 (84;0;0)
options: -emacs +ignoreeof +noclobber +vi +cdspell +direxpand +dotglob +extglob +globstar +histappend -hostcomplete +inherit_errexit

Hi - I not-infrequently get a Processing Input... indicator that will take 5-10 minutes to complete & won't react to ctrl-c basically bricking the session. I'm not sure where it is coming from exaclty but suspect tab complete and hints. It often happens when large commands are pasted (e.g. by the vscode debug launcher), but also just ls ~/.bl<TAB> can trigger it:

One example completion after allowing it to spin for ~15min:

 09-01 18:05 ~/cod/per/dot main ✘!?⇡  (line 53) ...
nt_command}currnt_command}currnt_command}currnt_command}currnt_command}currnt_command}...currnt_command}x

I know the root cause here might be an error in a script or extension, but I am wondering if there is r would be a better way to handle or troubleshoot such cases.

blerc:

bleopt history_share=1

# redraw on resize
bleopt canvas_winch_action=redraw-prev

# legible syntax errors
ble-face syntax_error=bg=88,bold

ble-import -d integration/fzf-completion
ble-import -d integration/fzf-key-bindings
_ble_contrib_fzf_git_config=key-binding:sabbrev:arpeggio
ble-import -d integration/fzf-git

## Ctrl-C behavior
function ble/widget/discard-and-cancel {
  ble/widget/discard-line
  ble/widget/history-end
}


function _on_auto_venv {
  bleopt keymap_vi_mode_string_nmap=$'\e[1m-- NORMAL -- '"$(_current_venv_info)" 2> /dev/null
}

function blerc/vim-load-hook {
  ble-bind -m vi_imap -f C-c 'discard-and-cancel'
  ble-bind -m vi_nmap -f C-c 'discard-and-cancel'
  ble-bind -m vi_nmap -f C-r isearch/backward
  ble-bind -m vi_nmap -f C-m accept-line
  _on_auto_venv
}

blehook/eval-after-load keymap_vi blerc/vim-load-hook

[akinomyoga]

Hi - I not-infrequently get a Processing Input... indicator that will take 5-10 minutes to complete & won't react to ctrl-c basically bricking the session.

You may forcibly cancel the current input processing by C-\.

I'm not sure where it is coming from exaclty but suspect tab complete and hints.

It happens when there is a large input from the terminal. As far as I know, the input processing isn't triggered by the TAB completion and auto-complete.

It often happens when large commands are pasted (e.g. by the vscode debug launcher),

This is the typical situation where the input processing blocks, though 5-10 min seems unusually long.

but also just ls ~/.bl<TAB> can trigger it:

This is strange. Is this the same issue? Do you really see the message "(...% processing input ...)" also for this case?

One example completion after allowing it to spin for ~15min:

 09-01 18:05 ~/cod/per/dot main ✘!?⇡  (line 53) ...
nt_command}currnt_command}currnt_command}currnt_command}currnt_command}currnt_command}...currnt_command}x

This happens when the completion setting produces a very long candidate. What is the result of the following command?

$ complete -p ls
$ declare -p _fzf_orig_completion_ls

[micimize]

Ooh, C-\ will be a lifesaver, thank you!

Is this the same issue? It is, same behavior but could possibly have been from the keystroke prior. I can't trigger/repo the behavior manually thus far.

complete info:

~$ complete -p ls

complete -F _fzf_path_completion ls
~$ declare -p _fzf_orig_completion_ls
declare -- _fzf_orig_completion_ls="complete -F %s ls #_comp_complete_longopt"

fzf does seem like the top candidate culprit to me as well. Does ble.sh have a flag for writing debug/trace logs to a file or something like that? Or would that not make sense to do

[akinomyoga]

Does ble.sh have a flag for writing debug/trace logs to a file or something like that? Or would that not make sense to do

There's a profiler as described here, but the full logging is dangerous for the present situation because the filesize of the log may grow up to terabytes in the present case. It is better to do partial logging one by one. To save the trace log for the completion function _fzf_path_completion, you can run the following command:

$ ble/function#advice around _fzf_path_completion 'ble/debug/xtrace.advice ~/blesh-issue624.txt'

After that, you can try to complete by

$ ls ~/.ble<TAB>

Please monitor the size of ~/blesh-issue624.txt while waiting for the results. If it grows into an unrealistically large size, please kill -9 the Bash process. Then, a file is created at ~/blesh-issue624.txt. You can attach the file by dragging and dropping it into a GitHub textarea.

[akinomyoga]

Is there any progress?