19 ms·
I do not follow the argumentation. LSPs are created for text editors. They are focused on lightweight text editor presentation. If you want to expose AST, you e
by oaiey 3y ago
I do not follow the argumentation. LSPs are created for text editors. They are focused on lightweight text editor presentation. If you want to expose AST, you either start implementing clients again (defeating the original purpose) or you start being 3-7 levels down the abstraction madness. You can do that and projecting ASTs instead of representing text (looking at you JetBrains MPS) but even the best IDE companies in the world has abondon that in favor of being text based.
With that LSP would not solve the n x m problem of editors to languages but would require all text editors to reinvent themselves into something completely different.
- cmrdporcupine 3y agoPart of the problem is that the LSP protocol & model simply can't work with systems that aren't text-file-based; like a Smalltalk, say. Or stored procedures in a database. Or other heterodox models. It makes the (probably reasonable) assumption that all development happens in file-based text editors, and imposes the text editor model. That's fine, but there are other ways to organize code objects, and the LSP ecosystem is mainly useless to them. Which is frustrating for the people working in or on that model, but maybe of no concern to others and probably no reason VSCode etc would want to have focused on the possibilities of that alternative. But it means people doing the heterodox will have to reinvent the wheel completely instead of partially.
- oaiey 3y agoBut that is something you can fix when you virtualize the file system. In the end it is text. And I think there is some movement. See other comments.