According to the VS Code extension documentation, [langId].trace.server is used to set the trace value for both the client and the server.
However, in the Ruff extension, this value is ignored on startup, because it is immediately overridden when we set the trace value from getLSClientTraceLevel. This function determines the trace level from the output channel's log level. What this means is that by default, Ruff's actual trace level is almost always "messages" instead of "off", which is the default value of ruff.trace.server. This is confusing and counterintuitive - if you actually want to turn off tracing messages in Ruff, you'll have to change ruff.trace.servertwice from the extension settings window (once to a different value from the one you originally set, and then back to the intended value). And this will get clobbered when the server restarts, so you'll have to do this a lot.
I propose that we remove getLSClientTraceLevel altogether and use ruff.trace.server as a single configuration point for tracing.
According to the VS Code extension documentation,
[langId].trace.serveris used to set the trace value for both the client and the server.However, in the Ruff extension, this value is ignored on startup, because it is immediately overridden when we set the trace value from
getLSClientTraceLevel. This function determines the trace level from the output channel's log level. What this means is that by default, Ruff's actual trace level is almost always"messages"instead of"off", which is the default value ofruff.trace.server. This is confusing and counterintuitive - if you actually want to turn off tracing messages in Ruff, you'll have to changeruff.trace.servertwice from the extension settings window (once to a different value from the one you originally set, and then back to the intended value). And this will get clobbered when the server restarts, so you'll have to do this a lot.I propose that we remove
getLSClientTraceLevelaltogether and useruff.trace.serveras a single configuration point for tracing.