-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Formatting can be delayed by slow IntelliSense operations #6156
Comments
Adding @Colengms to help look into this. As I said in the other issue, the formatter is purely lexical and doesn't require processing included headers, so it shouldn't be related to your usage of boost. If you can enable Debug logging and share the output that appears when you try this, I think that would be a good starting point for the investigation. |
Thanks! I think the debug log makes it clear what's happening here -- the language server is stalling while attempting to serve a completion request (triggered while I was typing), and then the indentation request only goes through after the completion request is canceled. Here is the log:
|
There are a few possible issues here. It's possible another IntelliSense operation was occurring, which can cause subsequent requests to our message handler (such as format on-type requests) to be delayed. @kevinushey , can you provide the output of the C/C++ channel while this repro's, perhaps using a similar animated image, so we can see the timing? (The log you just posted as I was typing this seems to confirm that hypothesis). Depending on the complexity of the code-base, IntelliSense requests that could block on-type formatting could take a significantly long time. Another problem is that asynchronous on-type formatting is fundamentally flawed, IMHO. It only works if we can always service it immediately, before the user types the next character. If formatting takes longer than a single keypress to process, the results are discarded. An issue here can be repro'ed simply by holding down a key that triggers formatting (i.e. enter, with indent rules enabled). Ideally, formatting should not be asynchronous, but all interactions between VS Code and extensions are asynchronous with regard to user input. I suspect we may need to remove vcFormat's indent on-type features. |
Regarding the extra closing paren: That seems to be a VS Code issue. I can repro with formatting disabled, by pressing enter between typing params, before typing the closing paren. |
I would overall agree with this. Rather than relying on formatters to perform as-you-type indentation, I think that indentation should be handled by a custom command (bound to the Return key) that makes "best guesses" as to what the right indentation should be. Such an indentation system could either rely on regular expressions, or an ad-hoc walk of a simple tokenized representation of the document (basically just doing bracket counting or looking for "special" tokens to guess what the right indent is). (For what it's worth, this is basically what the python indent extension does, except it relies on the python-indent-parser module for the heavy lifting) |
I believe this issue has been addressed. IntelliSense operations have been moved off of what is essentially the 'main thread', allowing operations such as formatting to be processed without waiting for IntelliSense operations to complete. It's possible that other operations on the main thread could take longer than expected, but the IntelliSense operations were the most significant. |
Thanks! Unfortunately, the experience here is a bit janky for me -- there's a substantial pause between the time when I insert a newline, and when indentation is applied. It seems like sometimes the indentation attempt just ... times out? It's worth saying that I'm editing a file with a substantial number of large header includes (e.g. Boost); not sure if that effects things here.
If I'm typing quickly, then no attempt at indentation happens at all (and also notice a rogue right parenthesis gets duplicated; normally
)
insertion would just move over the already-inserted paren):All that said -- rather than a "smart-enough post-hoc indentation system", I'm really hoping that cpptools could just immediately place the cursor in the "right" place after a newline is inserted. (I imagine this is incredibly challenging to solve in general due to the complexity of the C++ grammar, but I think at least in this case it should be easy?)
It seems like a lot of C++ developers using VSCode are used to this workflow (write code without as-you-type indentation, and then format afterwords using an appropriate formatter) but coming from other editing environments (e.g. Vim) I'm used to seeing the cursor just "be in the right place" with newline indentation.
Originally posted by @kevinushey in #883 (comment)
The text was updated successfully, but these errors were encountered: