Wait, why are we checking if stderr is a TTY, instead of stdin?

Hah, oh man. Because I apparently haven't fully woken up yet. Fixed.

In a real LSP scenario, both stdin and stdout are probably connected to the LSP client. Not sure if it's guaranteed that stderr captured/piped as well? Like, I could imagine a scenario where you want to query information from an LSP server from a CLI application. In this case, you might just want to inherit stderr from the parent process to surface any errors from the LSP directly to the terminal?

That should work since stdin won't be considered a tty. If the initialization options you send to the LSP server after starting it doesn't have a log file, then tracing is configured to write to stderr.

Did you consider using tracing::warn! here? (do we show these by default?)

Yes. It was the first thing I tried, but it's not shown by default.

The issue is that our tracing stuff isn't configured until the server receives its initialization options. But that's well after the point that an end user trying to run ty server directly will be confused.