very slow with large command

[simonLeary42]

There's a significant delay between when I press a key and when I see a character appear on screen. It seems that adding an open parentheses to the front really grinds BLE to a halt.

• I notice that it's much faster to type at the end of the command than it is at the beginning.
• Once this long command is in my bash history, I now get blocked up when cycling through previous commands with the up/down arrows. The same goes for searching previous commands with ctrl+R.
• after disabling vim mode, it's faster but still not usable.
• disabling syntax/filename/variable highlighting did not make a difference.
• after I paste, the progress bar pauses the longest at 85% "constructing text"

It seems to me like the solution is for me to open a proper editor with <ctrl+x><ctrl+e> before I want to paste a big command. If this problem is commonplace, would it make sense to add a feature for BLE to detect large inputs and do this automatically?

GNU bash, version 5.2.26(1)-release (aarch64-apple-darwin23.2.0)
ble.sh, version 0.4.0-devel4+32f290d (noarch) [git 2.44.0, GNU Make 4.4.1, GNU Awk 5.3.0, API 4.0, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
locale: LANG=en_US.UTF-8 LC_TERMINAL=iTerm2 LC_TERMINAL_VERSION=3.5.5
terminal: TERM=xterm-256color wcwidth=15.0-west/16.0-2+ri, iTerm2:3.5.5 (41;2500;0)
options: -emacs +pipefail +vi +autocd +cdspell +dirspell +failglob +globstar +histappend +inherit_errexit +login_shell +no_empty_cmd_completion +nocaseglob

[akinomyoga]

If this problem is commonplace, would it make sense to add a feature for BLE to detect large inputs and do this automatically?

Have you checked bleopt line_limit_type and bleopt line_limit_length? How is it different from bleopt line_limit_type=editor?

[simonLeary42]

ah, you already implemented this! After setting line_limit_type to editor and lowering the limit, I am redirected into vim when I paste a large command. However, I'm also redirected into vim when I press the up arrow, and then if I :q then it executes the command, and then I can't get to another command further back in my history.

[simonLeary42]

I think in a perfect world, the behavior when cycling through command history using up/down arrows would be something like:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, ... TRUNCATED, PRESS ENTER TO EXPAND

[akinomyoga]

ah, you already implemented this! After setting line_limit_type to editor and lowering the limit, I am redirected into vim when I paste a large command. However, I'm also redirected into vim when I press the up arrow, and then if I :q then it executes the command, and then I can't get to another command further back in my history.

I think in a perfect world, the behavior when cycling through command history using up/down arrows would be something like:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, ... TRUNCATED, PRESS ENTER TO EXPAND

I doubt it would give a natural and consistent user experience. I'd rather suggest setting bleopt history_limit_length to a number less than or equal to bleopt line_limit_length.

[simonLeary42]

Oh, you've really thought of everything.

Since the UX when history_limit_length > line_limit_length and line_limit_type==editor is very unnatural, do you think guard-rails should be put up to avoid this configuration? I'd be willing to put some development time in if you think it would be worth it for bleopt to detect and warn users when they make configurations that are known to cause strange/broken behavior.

[akinomyoga]

Wouldn't just adding a note in the description of bleopt line_limit_type=editor suffice? The user wouldn't know line_limit_type=editor without reading the description.