Hacker News Reader

Comment by 59nadir | Hacker News Reader

> Even if we are using this latter model, the user is only editing one file at a time.

I'm not necessarily arguing against your bigger point but this is very frequently a wrong assumption and strikes me as designing around an idealized view of the problem that you would like to be the case, not actual reality. Code generation scripts, formatters, auto-fixers and the like can modify many files and many parts of those files "at a time", unless you have a pedantic view of what "at a time" means. Almost all LSPs fail in these modes of operation and disallow external tools from participating in the code base, which is very annoying and makes them less useful.

Having to actually (re-)open a file so the LSP can "see" changes made to it by an external program is not something that should ever be needed but happens a lot with some of the most worked-on language servers (TypeScript comes to mind).

View on HN

According to the spec it's up to your IDE to notify the LSP when files change (even due to an external software) then the LSP reads the new versions.

Typescript also doesn't use an LSP as it predates the introduction of LSPs.

What does it mean for a language "not to use an LSP"? The most straightforward way I can think to interpret that statement is that it's saying that a TypeScript language server doesn't exist at all, which certainly doesn't seem to be the case based on finding https://github.com/typescript-language-server as the top result when googling "typescript language server". I guess you might be saying that it's not a first-party language server, but I'm not really sure why that would be relevant when discussing properties of language server implementations; the implementation clearly exists, and even if very few people are using it, that doesn't mean GP's point about a flaw in its design wouldn't still apply.

I meant both VS Code and VS use tsserver which doesn't follow the LSP protocol. Yes there is an LSP for other editors.

I don't see the flaw in the design, it's more likely the editor isn't behaving according to spec.

Either way, all those files need to be marked dirty and reindexed, so I suppose I'm just not sure how the topic at hand is relevant. Is the proposal that we attempt to treat each dirtied file as though incremental edits were imminent? Because this is precisely the wrong assumption you're raising. Ultimately, if you need to reopen a file in order to see changes on disk reflected, that's a bug with your lsp server, nothing more.

> Either way, all those files need to be marked dirty and reindexed, so I suppose I'm just not sure how the topic at hand is relevant.

You stated an assumption as part of your argument (only one file is being edited at a time) and that assumption is very often false. If that assumption doesn't matter I don't know why you brought it up in the first place. I stated pretty clearly that I wasn't arguing against your larger point but the assumption you explicitly stated was false.

> Ultimately, if you need to reopen a file in order to see changes on disk reflected, that's a bug with your lsp server, nothing more.

You don't say? It's the kind of misbehavior you get when people make assumptions that are false and bake them into the design of things.

And that assumption is relevant in the context of OPs concern but not yours. You created a different hypothetical and orthogonal situation where the assumption need not apply, and to be honest, I lost the plot a bit. It's possible for there to be a branching set of concerns, each of which having their own set of perfectly valid but otherwise disjoint assumptions.

Reply on news.ycombinator.com