Hi,
I'm basically saying that when you do
M-x eglot-show-workspace-configuration
what it shows is JSON, which is nice to read, BTW.
So why not defining a way to place a default configuration for eglot written in JSON in ~/.emacs.d or wherever init.el happens to be?
LSP servers cannot always always be configured in a static way, practically speaking. Some require dynamic runtime parameters to be configured.
For all it's "user-unfriendlyness" LISP handles this transition between static data and dynamic invocation exceptionally well.
I'm in violent agreement :-) with this. My only objection is that I don't see a _beginner in Emacs_ needing this from day zero.
Someone with a basic knowledge of programming wants to do this with Emacs... in i.e. Python course.
If you were to try to translate this to JSON... How would do you do that? For all but the simplest cases, I feat this will complicate rather than simplify.
But with the "simplest case" you suddenly make Emacs more attractive for new users and once people get involved, we can 'confront' them with the more complex stuff.
Just to lower the entry barrier by a fraction.
This is a worthwhile goal, but I don't think I agree the approach suggested above is the best way to solve this, nor it being realistic.
I think the simplest way to lower the barrier to entry is by making sure the defaults works well for most programming languages, and that you don't need to have a "eglot configuration user experience", because why on earth would anyone want to have that? :D
Actually you would have the best of user experiences, right? ;-) But until this day comes, one of the areas I see more problems in conveying is the LSP.
There might be many ways to achieve this "no config, just works" scenario, but one very concrete and conceptually much simpler was suggested in a thread I personally started just a few days(!) before this one.
Also, I think I mentioned this before, but I would like to see major modes customising `eglot-server-programs', just like they modify `auto-mode-alist', seeing as the people who use and develop the major
mode are probably in the best position to test and evaluate the performance of a LSP server.
Nice idea, really. But with languages having more than one LSP, which one would be chosen? Some are good in one person's work-flow but may not fit in others...
I think that might be the simplest, best option overall?
- The LSP server-list is maintained by people with knowledge of LISP, Emacs-development, the programming-language in question, and the ecosystem surrounding that programming-language.
- Eglot-maintainers don't need to try to maintain knowledge across 2000+ different programming languages.
- The end-user installs/activates the relevant major-mode, and a good Eglot configuration should already be present.
Where do I have to sign to have this tomorrow? ;-)
As a major-mode developer, I have very few problems accepting such a convention, and it would also ease eglot-configuration for languages whose only major-mode is provided through MELPA or similar third party sources.
—
Kind Regards
Jostein Kjønigsen
1. to be able to edit the buffer created by eglot-show-server-configuration (which we are right now) <==
2. to be able to resend this modified buffer to the LSP again.