Recently I started adapting a new LSP php server (phpactor), which is another lsp supporting the PHP language, recently was debate about the organization of the servers #1673 , so the question is:
How should organize the increase language servers?
My opinion:
- There are some servers that require more extensive configuration, and can have more functionality aside from the standard that lsp provide. (for me, phpactor would be the this case)
- I think that the file lsp-clients is too much longer, a more directory per language approach could be more easy to organize.
So, what do you guys think?
Thank you! :+1:
Sasanidas
All 7 comments
ATM the options are two:
- Standalone file in lsp-mode repo, e. g. lsp-foo.el
- Standalone repo under emacs-lsp
The first one is more convenient for the users but lsp-mode gets bulkier and overloads the lsp-mode maintainers because all of the issue reports/pull requests go in this repo and at the same time the core maintainers cannot be experts in any languages.
The second one is a kind of commitment for the initial author to help and maintain that package because he is the maintainer and he gets the credit for the work.
I am fine with both.
yyoncho
on 5 Jul 2020
ATM the options are two:
1. Standalone file in lsp-mode repo, e. g. lsp-foo.el 2. Standalone repo under emacs-lspThe first one is more convenient for the users but lsp-mode gets bulkier and overloads the lsp-mode maintainers because all of the issue reports/pull requests go in this repo and at the same time the core maintainers cannot be experts in any languages.
The second one is a kind of commitment for the initial author to help and maintain that package because he is the maintainer and he gets the credit for the work.
I am fine with both.
I see, so don't touch the lsp-clients.el file?
Sasanidas
on 5 Jul 2020
I see, so don't touch the lsp-clients.el file?
Yes. lsp-clients.el was the initial idea then we saw that it wont work. ATM it is kind of deprecated and we might split it into several pieces.
yyoncho
on 5 Jul 2020
I see, so don't touch the lsp-clients.el file?
Yes. lsp-clients.el was the initial idea then we saw that it wont work. ATM it is kind of deprecated and we might split it into several pieces.
Sure, that's an interesting thing to do, a better organize approach in my opinion, I can work on it, if you are ok with it :+1:
Sasanidas
on 5 Jul 2020
I am fine with that - after you create the new files please keep lsp-clients.el and require the new files from lsp-clients.el to avoid making this breaking change. Then in the next release, we will delete lsp-clients.el.
yyoncho
on 5 Jul 2020
I think we can close this as lsp-clients.el doesn't exists anymore, right?
ericdallo
on 9 Oct 2020
I think we can close this as
lsp-clients.eldoesn't exists anymore, right?
Sure :hand:
Sasanidas
on 9 Oct 2020
Related issues
kmdouglass
路
3Comments
raxod502
路
5Comments
raxod502
路
4Comments
sid-kap
路
5Comments
alanz
路
6Comments
Most helpful comment
ATM the options are two:
The first one is more convenient for the users but lsp-mode gets bulkier and overloads the lsp-mode maintainers because all of the issue reports/pull requests go in this repo and at the same time the core maintainers cannot be experts in any languages.
The second one is a kind of commitment for the initial author to help and maintain that package because he is the maintainer and he gets the credit for the work.
I am fine with both.