Closed snowsignal closed 4 weeks ago
Do you know what the motivation was for using getLSClientTraceLevel
in the first place? Do we still need to support getLSClientTraceLevel
for the python LSP?
Personal preference: I like to include screenshots when making changes that change the visual output. The screenshot alone can communicate a lot of context to the reviewer. It's like, ahhh, you changed that part and it now looks like this. I like it!
@MichaReiser
Do you know what the motivation was for using getLSClientTraceLevel in the first place?
We took it from the Python tools extension template when we started building the extension. The template doesn't have a [langId].trace.server
setting - this was added later, in #114, and this was never removed. That's why we've had two competing setters for the trace level.
Do we still need to support
getLSClientTraceLevel
for the python LSP?
No, it also uses the [langId].trace.server
setting.
Personal preference: I like to include screenshots when making changes that change the visual output.
I've added screenshots 👍
Summary
Fixes #488.
We no longer override the trace level on server restarts. This means that the trace level will always be set to the value of
ruff.trace.server
.Test Plan
With
ruff.trace.server
set to"off"
, you should no longer see logs in the output marked as[Trace - ...]
.Before:
After: