3 ms·
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 c
by nh2 1y ago
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 https://nh2.me/flashing-cursors-on-newline.mp4
Why, and is there a way around it for those other terminals?
- nh2 1y agoFor Kitty I posted it on https://github.com/kovidgoyal/kitty/issues/8752 https://github.com/kovidgoyal/kitty/issues/8752, maybe we'll learn more!
- big_alfredo 1y agoTry tweaking kitty's input_delay setting. For example: kitty --override=input_delay=10
- nh2 1y agoinput_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/ https://sw.kovidgoyal.net/kitty/performance/ seem to affect its appearance.
- big_alfredo 1y agoInteresting, 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.