Previous commands (up arrow) only works after a small delay after pressing enter about ohmyzsh HOT 6 CLOSED

Is it reproducible as well if you're not in a git repository? Try in $HOME, for example.

from ohmyzsh.

I think terminal's application mode (smkx) is not yet ready when the prompt hasn't been drawn. If we bind a specific key sequence without using $terminfo we might have issues cross-terminal, i.e. when a different terminal emulator sends a different key sequence or the same for a different key combination.

We might be able to fix this one instance, but let's be vigilant for other issues.

from ohmyzsh.

Also if one holds the enter key, there is inconsistency in the line breaks - some have the shell prompt, some don't:

from ohmyzsh.

Is it reproducible as well if you're not in a git repository? Try in $HOME, for example.

Yes, the up arrow being stuck on a single command yes, the incosistency in line breaks, no.

Also it might be a bit harder to reproduce due to the reduced delay when pressing enter, so requires faster timing than when on a git repo it seems.

Also I could not reproduce it with ctrl + c, just enter.

from ohmyzsh.

The inconsistency with spacing is related to how the prompt is loaded (it checks git status before drawing). Basically if you manage to click enter before drawing it happens. You can reproduce it easier executing PROMPT+='(sleep 2)'.
That thing of pressing the up arrow, I can reproduce it as well. The problem is that the character sent to the terminal when the prompt is not drawn yet is ^[[A instead of ^[[OA, which in my case is the one that matches with "${terminfo[kcuu1]}".
Here we're setting that only for "${terminfo[kcuu1]}", and not ^[[A.

from ohmyzsh.

@mcornella what do you think about this? Should we bind as well ^[[A to avoid this behaviour?

from ohmyzsh.