Open dimaqq opened 1 month ago
I'm tempted to suggest it to be a configuration error to run tools on files not intended for them. Yet if assuming there actually are reasons to have such a setup, could you please consider completing the issue by explaining what you would expect the correct behaviour would be and elaborating on how to achieve a better user experience?
Actually I also experience similar, albeit less extreme, issue when editing a file with a merge conflict -- the >>><<<<
markers confuse the linter or static type checker and very many errors/warnings are produced.
Overall, I would like non-blocking behaviour, that is, even if the file is 2,000 lines long, vim+extension doesn't spend excessive time annotating every line (?) or every visible line (?) with errors.
ALE is meant to be asynchronous after all!
I think there may be a bad interaction between annotating the code with "fake" comments and the syntax highlighter.
Perhaps it's worth annotating the buffer in chunks? I'm fine waiting a bit for the errors to show, as it takes a while already. I'd like to be able to edit the code while the errors are being processed.
I've found a pathological case where vim becomes almost unusable.
The trick is to open a file that's not really a Python file, but try to syntax highlight it and annotated with pyright errors as if it were Python code.
Note that syntax highlighting alone works well enough.
Information
VIM version
Reproducing the bug
Run a virualenv with pyright installed (maybe other tools like ruff of mypy would do as well). Grab https://gist.github.com/dimaqq/925afea05590de55abd49ab631612738 Open it in vim. Wait. Wait some more... Watch the screen fill in slowly with annotations.