Re:Emacs: The Editor for the Next Forty Years [video]
by didibus on Wednesday November 27, 2019 @02:16AM
(#21645946)
Interesting angle.
That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold:
1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is.
2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.
That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold:
1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is.
2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.