[avianlyric]

> Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server.

VSCode cheats a little in this area. It has its own autocomplete engine that can be guided by extension config, which it mixes seamlessly into the autocomplete coming back from the LSP. The net result is better autocomplete in all languages, that can’t be easily replicated in other editors, because the VSCode augmentations can often be better than what an LSP produces.

[vintagedave]

Any idea how this works? It seems crazy that a generic engine can outdo a language-specific LSP server.

[avianlyric]

Mostly by being more flexible in its inputs and outputs than an LSP. An LSP is generally trying to perform deep static analysis on your code to provide suggestions. The upside is extremely accurate suggestions, with a pretty much 0 false positive rate (I.e. it never suggests anything uncompilable), the down side is that they tend to be much picker about their inputs.

If the code is currently in an un-parsable state, and a valid AST can’t be produced, then the LSP is forced to work with whatever parsed version of the code it was last able to build a valid AST for. Making the autocomplete results, incomplete.

VSCode on the other hand is basically performing tokenisation and fuzzy search on those tokens. It doesn’t really care about the validity of the code, that means more false positive suggestions (I.e. suggesting stuff that can’t compile), but very robust handling of un-compileable code. That plus prioritising LSP suggests over fuzzy suggestions, results in VScode providing a very nice graceful fallback for LSP failures, that people probably use more often than they expect.