-
-
Notifications
You must be signed in to change notification settings - Fork 223
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
Error popups when editing some invalid forms #1889
Comments
rewrite-clj
parsing errors
Thanks for the issue! I can't reproduce the issue with your example there. Maybe there is something more in your file you are testing with? |
I am getting intermittent results on that particular reduction of the problem as well. Typing into With only
|
Also copying the form that throws the error when you're typing to a new file means it no longer throws this error when typing. Haven't been able to figure out what's the issue too. |
It seems Calva never has its hands directly on the event flow that leads to this bug. We tell clojure-lsp to handle As things stands now, we are probably stuck waiting for resolution to clojure-lsp #1268. |
rewrite-clj
parsing errors
Here is a partial workaround until this can be solved: Adding this to your {
"key": "shift+escape",
"command": "notifications.clearAll",
"when": "notificationToastsVisible || notificationCenterVisible"
} |
Once the above PR is merged and deployed, the workaround above won't be needed. 🎉 |
All Calva's dependencies that use
rewrite-clj
, such asclojure-lsp
, commonly propogate parsing exceptions. (I'm guessing Calva's direct use ofrewrite-clj
does the same?) Calva then fails to handle these exceptions or actively throws them at the user, causing a popup modal, which shows the opaque message ofRequest textDocument/codeAction failed.
, and does not auto-dismiss itself.An example case that occurs frequently during normal (even if perfect) editing is caused by an unbalanced map anywhere between 2 parens.
The user experience is severely degraded by these unavoidable popups that only go away with manual intervention. Calva should catch these exceptions and route them to a Diagnostic. They can be reported to the user as equivalent to a linting error.
One question here is where in the document the error should be reported. (Pretty sure we won't have meaningful line and column numbers from a failed parse?) The obvious choice would be either the start or end of the document. My personal opinion is it would be more helpful to use the start or end of whichever line the cursor happens to be on. This ensures the user receives visible feedback from anywhere in the document.
The text was updated successfully, but these errors were encountered: