←back to thread

457 points benoitg | 3 comments | | HN request time: 0s | source
Show context
nh2 ◴[] No.44371598[source]
With or without starship, one problem I have with zsh prompts is that when I press Enter, there is still a visible delay where for a fraction of a second, the cursor moves to the beginning of the next line.

This makes a nasty "flashing" effect.

If I keep Enter pressed, the cursor is permanently visible at offset 0 in the lowest line.

If the prompt is ultra-fast (e.g. plain root shell prompt on zsh), it happens less (e.g. only 50% of cases), but as soon as the prompt does anything, it's very visible.

I observe this with many terminals (gnome-terminal, wezterm, kitty, alacritty, xterm).

The only terminal I tried that doesn't have this problem is urxvt, where it looks perfect.

Video repro: https://nh2.me/flashing-cursors-on-newline.mp4

Why, and is there a way around it for those other terminals?

replies(2): >>44376643 #>>44377645 #
1. big_alfredo ◴[] No.44377645[source]
Try tweaking kitty's input_delay setting. For example: kitty --override=input_delay=10
replies(1): >>44385973 #
2. nh2 ◴[] No.44385973[source]
input_delay doesn't seem to address this in general: Even when set to 50 (which is very noticeable), the cursor on the next line just appears with some delay.

None of the settings from https://sw.kovidgoyal.net/kitty/performance/ seem to affect its appearance.

replies(1): >>44388695 #
3. big_alfredo ◴[] No.44388695[source]
Interesting, In zsh I experienced the exact behavior you described and setting input_delay to 10 completely resolved it. To be fair, when testing my PS1 was simply '%m$ '.

I just benchmarked 'starship prompt' and when in a directory managed by git, it can take well over 10ms. I imagine with a more advanced configuration it would take even longer. urxvt must be doing something special.