[iTerm2 3.5] strange symbols during initialization

[tessus]

ble version: 0.4.0-devel4+afb2907 Bash version: 5.2.26(1)-release (x86_64-apple-darwin23.2.0)

When starting an iTerm2 window, I see strange symbols during the initialization of ble.

https://github.com/akinomyoga/ble.sh/assets/223439/41bee89d-4587-4aea-9b96-27628fbc59f4

This isn't really important, but I have noticed this behavior and since the init already takes a while, it is something the eyes are focussed on when opening a terminal. I can't say whether it is because of a newer ble version or it could've also started to happen after the update to iTerm 3.5.

This also happens when connecting to a remote machine (macOS, Linux) via ssh in an iTerm2 window. This does not happen on Linux in a KDE session when opening konsole.

[akinomyoga]

By default, ble.sh tries to detect the character-width scheme of the present terminal by sending characters and measuring their widths. It's not what is recently added to ble.sh; it's already been in v0.3. Usually, the measurements are performed in a very short time (probably shorter than one frame of the refresh rate of the terminal), and the characters are erased immediately after the measurements. Then, the terminal usually does not have a chance to render them, so you haven't noticed it so far. If something had changed, I guess it would be iTerm's algorithm to determine the timing of rendering a frame.

If you know the character-width scheme of the terminal in advance, you can set bleopt char_width_mode and bleopt char_width_version in your ~/.blerc. Only when they are set to auto, ble.sh performs corresponding measurements. You can check the desired values by running the following command after the initialization with auto. Those values are set by ble.sh after the measurements are performed.

$ bleopt char_width_@

However, I usually recommend to use the default value auto because the character widths change every year (as a new Unicode version is published every year), and we cannot predict when the user's system wcwidth (in libc, etc.) is updated to catch up the latest Unicode. If a user wants to specify the values manually, the user would need to check the desired values of the character-width scheme every time the terminal or the system is updated.

Maybe I can change the color of the character as the same as the background, or make it invis. Or another possibility is to use the terminal sequence "DECSET 2026" to suppress the rendering. iTerm2 should be supporting DECSET 2026 because its initial design was introduced by iTerm2, but a problem is that some terminals not supporting DECSET 2026 might print error messages if ble.sh sends the terminal sequence of DECSET 2026.

[tessus]

Thanks for the explanation. If DECSET is a problem, the color (or invis) option sounds like a plan. However, plesse don't waste too much time on it. It's annoying but isn't a functional issue. I don't want to be one of those guys who is known to nag about every little thing... ;-)

[akinomyoga]

I added a fix 8bb302e0930f0ea0f8996e3909b70cef3288027a to make the test characters invisible by using Terminfo's invis. I realized that it is hard to make the foreground color the same as the background color because there is no robust way to know the background color of the current terminal.

In commit c3df08bec94e74ef04d424d2a0b9d08c96d39908, I also enabled using DECSET(2026) when ble.sh detects the terminal supporting DECSET(2026) along with the iTerm2 detection https://github.com/akinomyoga/ble.sh/commit/da6e71db89e6f4a2be4f8c2c610ef4b418b9725a (though I haven't tested them with iTerm2 as I don't have macOS). I at least tested the behavior of DECSET(2026) with Mintty, Alacritty, and kitty, (though I don't see the difference in the experience so far), but it still might cause some side effects. @tessus Could you check the behavior of the latest master in iTerm2? You can update ble.sh by running ble-update in a ble.sh session.

[tessus]

Thanks, the characters are gone. Yeah! But the cursor still jumps around. Maybe I forgot how it was (before this behavior), but I've never noticed the moving of the cursor before the prompt shows up:

https://github.com/akinomyoga/ble.sh/assets/223439/cd90401a-f644-4eaa-83ab-5b1950040e1e

[akinomyoga]

Thanks!

But the cursor still jumps around. Maybe I forgot how it was (before this behavior), but I've never noticed the moving of the cursor before the prompt shows up:

Hmm. Since you didn't notice those characters until recently though ble.sh has been doing this for more than five years since 3978df3b89063514515985eda337cefa12b90085, I think iTerm2 should have changed its rendering algorithm. For example, as one possibility, iTerm2 may have started to force rendering on the CPR (CURSOR-POSITION REPORT) request.

I think I can also hide the cursor during the test using Terminfo's civis in the next push to the master branch. What is the result of the following command in iTerm2?

$ declare -p _ble_term_civis _ble_term_rmcivis

[tessus]

It is possible that iTerm2 changed some stuff when they released version 3.5.0. e.g. I don't see the cursor move in the stock Terminal app. But I believe most people use iTerm2 on macOS.

Here's the info you requested:

$ declare -p _ble_term_civis _ble_term_rmcivis
declare -- _ble_term_civis=$'\E[?25l'
declare -- _ble_term_rmcivis=$'\E[?25h'

[akinomyoga]

Thanks. OK, ble.sh seems to correctly detect civis and the corresponding sequence to clear it in your environment. I'll later push another fix.

[akinomyoga]

@tessus I thought the intermediate rendering by iTerm2 could be suppressed by DECSET(2026), but now I'm not sure if it is the case because CPR requests seem to force the rendering. Could you observe the behavior of the following commands iTerm2?

$ esc=$(printf '\e[8m'; printf '\r%s\e[6n%s\e[6n' {1..30}; printf '\e[m')
$ echo "$esc"
    # <-- Is the cursor jumping around here?
$ echo $'\e[?2026h'"$esc"$'\e[?2026l'
    # <-- Is the cursor jumping around here?

I'm also interested in the responses in the form of ^[[<row>;<col>R^[[<row>;<col>R... in each case to confirm that DECSET(2026) does not interfere with CPR.

[tessus]

Ok, here you go:

https://github.com/akinomyoga/ble.sh/assets/223439/9686eeb7-dfe1-4087-92cd-16e1350b88b1

[akinomyoga]

Thanks! OK, great! So DECSET(2026) does seem to suppress updating even with the presence of CPR requests.

[akinomyoga]

I pushed a workaround for jumping cursors in 0ff29b264c01e40e8c63bc4249af8367089c09a3 along with refactoring cc9d7f39bebdac3d885f929b55fef1741e339e11. Could you check the behavior? Thank you!

[tessus]

Works great. Thank you!

[akinomyoga]

Thank you for your prompt reply! Is everything fine now? Can I close the issue?

[tessus]

Yes, please go ahead. Thanks again for fixing this, even though it wasn't a functional issue, but rather a cosmetic one.

[akinomyoga]

Thanks! Reports for cosmetic issues are also welcome!