New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syntax highlighting aborts on enter for commands #5912
Comments
I'm assuming "enter" here sends |
I logged this as I'm suspicious about the whole thing. It shouldn't take long at all for If it is indeed the case, that makes sense. |
fish's normal syntax highlighting mode will check the filesystem to validate commands, underline paths, check redirections, etc. It also has a zero-IO mode, which is invoked right before executing a command. In this mode all commands are assumed to be valid, intended to address exactly this issue. So this is supposed to work, I'll investigate why it's not. |
Ok, we don't invoke the no-io variant of highlighting on every execution, because if the command really is invalid then we'll color it valid before failing to execute it. What happens here is that Note that it is not trivial to verify that I think the right thing to do is to wait for any outstanding background highlighting to complete, but with a timeout of a few ms. |
@ridiculousfish Is that already possible? And if so, how? I'm happy to accept the validation time of the command to get syntax highlighting for this use case. |
I still don't find #7418 duplicate with this. If so, then the problem is not just "wait for the time that fish processes colors", it is a problem regarding the order in which fish does expansions and colors the output, and, generally, the order in which fish does other things. |
@Ravenclaw-OIer I think your issue is indeed related to this one. And yes you're assumption that "it is a problem regarding the order in which fish does expansions and colors the output, and, generally, the order in which fish does other things" is absolutely correct. One quote from that thread:
|
Well, then I think we need to compile a list of "confusing coloring" and check them one by one after we close this. |
…ation It may happen that the user types an abbreviation and then hits return. Prior to this commit, we would perform a form of syntax highlighting that does not require I/O, so as to not block the user. However this could cause invalid commands to be colored as valid. Introduce a new function which performs background I/O and then waits for a little bit (250 milliseconds) for it to complete. If it does not complete in time, fall back to the no-I/O variant. This fixes fish-shell#7418; a followup commit will address the more general fish-shell#5912.
I believe this is solidly fixed with d3192d3. With that fix, commands wait for a little bit for outstanding syntax highlighting requests to complete, but with a timeout of 250ms. The hope is that commands will be colored correctly more often, but if syntax highlighting takes more than 250ms (e.g. an unresponsive NFS hard-mount) then we give up, color things optimistically, and execute. Note this is strictly about syntax highlighting and does not affect the order of any fish script execution. |
@ridiculousfish You're awesome! Thank you so much! Tried it right now and it's working like a charm. 🎉 This was bothering me for many years already. 🙈 |
If you're in a laggy environment (in my case, connecting to a tmux session over ssh - albeit on the local network, but over wifi) and type faster than fish is processing things, an
<enter>
after a command appears to abort the syntax highlighting process.In this example, I typed in
make
followed by<enter>
:Naturally, the command starts off as not found and in red (
m
,ma
,mak
) but is located and turned to the regular command color as the command (make
) is entered. I am hitting<enter>
before fish gets a chance to update that, and the highlighter continues to display it in red.If I were to pause for 100-200ms after typing in
make
before hittingenter
, this would not happen.The text was updated successfully, but these errors were encountered: