4 ms·

Language Server Protocol brings this to many editors that historically lacked it, including Emacs' lsp-mode. I use it a lot (with clangd), it's great. Because i

Language Server Protocol brings this to many editors that historically lacked it, including Emacs' lsp-mode. I use it a lot (with clangd), it's great. Because it's a common interface used by all editors, there is a lot of interest in and work on the language backends.

worldsayshi 7y ago
I'm all for standardizing this but I can't hear about the Language Server Protocol without thinking about this rant: https://youtu.be/pW-SOdj4Kkk?t=2549 https://youtu.be/pW-SOdj4Kkk?t=2549 The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
- taeric 7y ago
  Thanks for that link. I confess I have my own prejudices against LSP. This view just strengthened it some. Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.
- didibus 7y ago
  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.
- didibus 7y ago
  I started using Emacs about a year ago and I love it!! The thing with Emacs is that you need to embrace Elisp, and the workflow of working inside a REPL. If you're someone who like to have things your way, and who are more comfortable with a programming language then a UI, Emacs is for you! I personally use Spacemacs in Holy mode with Ivy and my own customization and some custom layers. I find this to be a great combination. I use it for Clojure development with Cider and Java development with lsp-java. And for editing most files, like configs, scripts, bash files, json files, etc. I also use it for notes in org-mode. The only things I rely on a different editor is Vim and less for dealing with large files like log files, and Notepad++ for when I need to do fancy search and replace stuff especially if the file is large.

worldsayshi 7y ago

I'm all for standardizing this but I can't hear about the Language Server Protocol without thinking about this rant: https://youtu.be/pW-SOdj4Kkk?t=2549 https://youtu.be/pW-SOdj4Kkk?t=2549 The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.

taeric 7y ago
Thanks for that link. I confess I have my own prejudices against LSP. This view just strengthened it some. Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.
didibus 7y ago
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.
didibus 7y ago
I started using Emacs about a year ago and I love it!! The thing with Emacs is that you need to embrace Elisp, and the workflow of working inside a REPL. If you're someone who like to have things your way, and who are more comfortable with a programming language then a UI, Emacs is for you! I personally use Spacemacs in Holy mode with Ivy and my own customization and some custom layers. I find this to be a great combination. I use it for Clojure development with Cider and Java development with lsp-java. And for editing most files, like configs, scripts, bash files, json files, etc. I also use it for notes in org-mode. The only things I rely on a different editor is Vim and less for dealing with large files like log files, and Notepad++ for when I need to do fancy search and replace stuff especially if the file is large.