Warp
Warp copied to clipboard
Keypresses are missed while a command is completing
Discord username (optional)
gthb
Describe the bug
When a command is completing, I invariably start typing the command I want to run next. In Warp this frequently misses keypresses, in particular `git` frequently becomes `gt` or `gi`. I suspect this is some bug involving buffering of keypresses while the previous command handling is wrapped up.
To Reproduce
Steps to reproduce:
- Execute
sleep 30
- Hit Ctrl-C and immediately type e.g.
git log something
- You will often (though not reliably) see some character be missing in the command you typed
Expected behaviour
I expect every key I pressed be captured into the work-in-progress command line for my next command.
Screenshots
No response
Operating System
MacOS
OS Version
10.15.7
Shell Version
zsh 5.7.1 (x86_64-apple-darwin19.0)
Additional context
No response
Warp Internal (ignore): linear-label:24888f54-df93-45d5-9bdd-e38f740cac19
No response
I've been seeing this super frequently too, I thought I was going crazy! I frequently type...
-
git add -A
- [ENTER]
-
git commit -m "message"
...but the commit command ends up as some kind of mish-mash of gi commit
or gt commit
I'm currently seeing it with version v0.2022.06.20.09.15.stable_02 but I've had this issue for a couple of months across different versions. macOS v12.3.1
FWIW, I tried escalating this on Warp discord, but it seems like the Warp team is clubbing this with another feature request (#56). The latter doesn't have an ETA either.
Thread: https://discord.com/channels/851854972600451112/852249738002956311/991085072608276580
@zachlloyd: Sorry to pull you in, but as a developer it's hard for me to understand why the Warp team is giving the same urgency to bugs as feature requests. Someone took the effort to file this issue almost a month ago, but no one from the Warp team has even acknowledged it yet. Can you shed some light please?
@alokedesai mind working with these folks to see if you can repro? I haven't been able to repro locally.
@bothra90, my apologies - are intention is to at least ack every bug within a day of its filing but we dropped the ball here. We are definitely trying to fix bugs as quickly as possible and apologize for any frustration here.
@bothra90 Apologies for the issue and thank you for flagging to us. Would you be able to share a video of the issue occurring? Does the bug repro if you comment out everything in your RC files?
Here's an example I come across really frequently. No ~/.bashrc
or ~/.warprc
files. This is a sizable git repository so status and add commands can take a couple of seconds. Here are the commands I ran...
-
git status
-
git add -A
(Originally typedgit add 0A
and corrected it, but it happens even if I don't do this) - Warp stopped showing input as I type at this point
-
git commit -m "Update
The final command came out as gupdate
If I'm fast enough at typing I can reproduce with these three commands about 70% of the time. I don't think it's specific to the git commands, I have seen it with others too, but this seems to be the one I see it with most frequently.
Here's a video of the bug
https://user-images.githubusercontent.com/103586/177277900-f014aa9c-16e8-4481-b4da-d32f75188b36.mov
Thanks so much for the video and repro instructions. It appears to be an issue with our typeahead implementation. We will prioritize reproing and fixing on our end.
On Tue, Jul 5, 2022 at 3:53 AM Thomas Beverley @.***> wrote:
Here's an example I come across really frequently. No ~/.bashrc or ~/.warprc files. This is a sizable git repository so status and add commands can take a couple of seconds. Here are the commands I ran...
- git status
- git add -A (Originally typed git add 0A and corrected it, but it happens even if I don't do this)
- Warp stopped showing input as I type at this point
- git commit -m "Update
The final command came out as gupdate
If I'm fast enough at typing I can reproduce with these three commands about 70% of the time. I don't think it's specific to the git commands, I have seen it with others too, but this seems to be the one I see it with most frequently.
Here's a video of the bug
https://user-images.githubusercontent.com/103586/177277900-f014aa9c-16e8-4481-b4da-d32f75188b36.mov
— Reply to this email directly, view it on GitHub https://github.com/warpdotdev/Warp/issues/1428#issuecomment-1174735657, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSUZK23JZHNZ3W3QQSARLVSPSX7ANCNFSM5XRSQLZA . You are receiving this because you were mentioned.Message ID: @.***>
@Thomas101, just to confirm in this example, did you type git commit -m "Update
before git status
finished executing?
In other words, were the steps:
- Execute
git status
-
while
git status
is executing: Typegit add -A <enter>
-
while
git status
is executing: Typegit commit -m "Update
@Thomas101 Also, if you you replace git status
and git add -A
with sleep 3
are you still able to reproduce? Thanks so much with your help here!
just to confirm in this example, did you type git commit -m "Update before git status finished executing?
From a few tests here, I think git status
might still be executing when I start typing git commit
. It looks like it's piped its output to the terminal, but hasn't actually finished running.
If I do git status
, git add -A
. That always works
If I do git status
, git commit -m "...
. That always works
It's definitely around running three commands in succession.
Also, if you you replace git status and git add -A with sleep 3 are you still able to reproduce? Thanks so much with your help here!
Yes. You need to make sure you're typing as the second sleep command executes. A long git commit message works really well. Or in fact, typing the lyrics to Fresh Prince of bell air also fails 🙈
sleep 3
sleep 3
git commit -m "My message"
-> git commit -m
I've uploaded a screen recording, just in case it gives any hints. In the screen recording, you can even see the input as I'm typing shows up as git commit -m "
, but after the second sleep command drops the quote and space to be git commit -m
https://user-images.githubusercontent.com/103586/178214655-d748cc05-497c-44ba-8eae-28dfe667ab7f.mov
Let me know if you need anything else, I know reproducing is half the problem 👍
I'm also able to reproduce something similar consistently on my system and had the same reaction as @Thomas101 -- I thought I was going crazy and fat fingering commands. Finally took a moment to record.
For me, it doesn't require 3 commands to be running. I can simply run one and start typing the next and it will lose a character while typing the second command.
https://user-images.githubusercontent.com/629120/178305761-16949fc4-f826-4297-815f-81fe00e073ae.mp4
@joshmatz -- in the video you have linked above did you type all the characters in git checkout
? It's also interesting that only git check
was echo'd back by the shell instead of git checkout
.
Also does this repro if you start a shell with everything in your RC files commented out?
want to chime in with the same issue. Let me know if you need any help reproducing, will do my best to help.
I've had this happen a few times, and I've finally been able to reproduce it consistently by running a cd
and then typing.
Someone mentioned having an empty RC file. I most definitely do not have an empty RC. Things that might be involved are direnv and the oh-my-zsh plugins for git and nvm. If I change directories and try to type a command before the prompt returns, I nearly always lose two characters. I don't even have to type quickly. I just have to by typing as the cd
completes. Even "asdf" typed over the space of about a second does it. It looks just like what @joshmatz captured in his video. You see part of the input echoed in the shell, a character or two is missed, and then you get the rest.
I'm also affected by this, I took the habit to launch a command and start typing while it's executing.
Example:
Typing g s
for git status
Not waiting for the command to complete, typing directly g co ...
for git commit
In warp, only co
is showing, the first character g
isn't appearing
It systematically occurs when I'm typing these commands fast
But if type sleep 5
And g s
while it's waiting
The command runs normally 🤔
Hey all! Just an update here: we are actively investigating this and prioritizing a fix. Should have an update shortly about when we think this will be resolved in our stable build
Hey folks, just as an update: we have a fix for this that should be coming out this Thursday!
Glad to see a fix is forthcoming. I've stopped using Warp because of this bug. I'm getting dozens of zsh: command not found: gi
type errors a day
The fix went live in v0.2022.10.04.08.05.stable_00
! Please let me know if you're still seeing the issue
Seems to work on my setup, thanks for the work 💪
I'll close this issue out for now, but feel free to re-open if the problem persists.