-
Notifications
You must be signed in to change notification settings - Fork 69
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
Diag channels #543
Diag channels #543
Conversation
- Removed Info, Notice and Debug feedbacks from the standard diagnostics
- The feedback type encodes the channels in which the feedback will be displayed in the client - The accessor will be used in the lspManager to forward these feedbacks in a custom lsp verb
- PublishCoqFeedback and params in extProtocol
- CoqFeedback notification type - Seperate channels for each type of feedback (Debug, Info. Notice) - Appends the results in the corresponding channels
- Seperated tests in feedbacks (Notice, Info, Debug) and diagnostics (Error, Warning)
I am still not sure if this is the right way to go @maximedenes.
How do we reconcile the two ? This PR aims at throwing Debug | Info | Notice into their own dedicated channels in the extension and Warning | Error in the usual Problems channel. Maybe at least the separation should be clearer in the backend. What do you think ? |
Yes, I think the distinction should be clear: only Error and Warning should be emitted as diagnostics (for now). Notice & Info feedback should be collected by the server and sent for display to the dedicated channels. I'm not sure about Debug, but we can see that later. |
- Seperated CoqFeedback types and Diagnostics types more clearly - Changed the diagnostics function to a feedbacks_and_diagnostics function - Reworked the code and the tests to take that into account
Appending the different types of coq feedbacks (Debug, Info, Notice) in separate channels instead of treating them as diagnostics