I think just giving a ready-to-use shell script to people for doing stuff like installing language servers is good enough, though I agree with Joao that the more stuff that is automatable be automated the better. I just tried eglot for Julia via eglot-jl. It didn't work (
https://github.com/non-Jedi/eglot-jl/issues/14), though the bug might be ... Julia's fault. (One of the problems with emacs now is exactly this; As we lack enough users, the support always lags behind. This might not be fixable without having a sizable portion of the users.) I just tried running `eglot` for python (though I'm quite happy with `elpy`, which I just wasted an hour to get to work with Doom Emacs because of incompatibilities.), and I got this conflict error `eglot--error: [eglot] -32602: pkg_resources.VersionConflict: (jedi 0.16.0 (/Users/evar/anaconda/lib/python3.7/site-packages), Requirement.parse('jedi<0.16,>=0.14.1'))`. I imagine this should be easily fixable by installing a suitable jedi version, but you get the idea. Here in emacs things have a way of not working by default, and I personally have low confidence for investing time in getting things to work. Now jedi is broken, then another thing might be. (I'm not trying to rip on eglot, it actually seems the nicest `modular language support` system of emacs that I have seen, and it is clearly going in the right direction. BUT things don't work by default.) I have, coincidentally, read through quite a bit of VSCode's issue on extending support of notebooks to other languages besides python, and the devs there are obsessive with making things work even when they are clearly NOT abiding by standards they should be abiding by (non-standard install locations, non-existent jupyter kernels config, etc). This is one of the reasons they are having problems supporting new languages. (Their current system is very python-tangled and seems to use private APIs of jupyter or sth.)
As I pointed to earlier, `elpy` was incompatible with Doom Emacs, and I spent an hour figuring out why elpy is not working. This is a direct result of Doom being a third-party system. Emacs ecosystem is highly fractured. If there was a first-class emacs distribution system, then elpy and elpy tutorials would not be incompatible with it. Important things that have the potential to break other stuff (modular emacs distribution, lsp support) need to be implemented first-party so that the community can converge on them. Here `first-party` means it should be endorsed by the core team, and it should have some manpower dedicated to it.
On a sidenote, I just saw abo-abo's package for editing python a la lispy. These REPL-centered, keyboard-first experience of editing code is emacs' greatest strength and selling point to me, along its extensibility. I think a more directed approach to unfracturing emacs users and making development efforts of users more centralized to avoid duplication of efforts and deliver preconfigured workflows that can be tweaked if need be, will go a long way to revitalize emacs.
On another sidenote; The greatest weakness I see in VSCode is its culture. The culture there does not see the value of extensibility, keyboard-first workflows, interactive development, and generally investing in your tools and shaping them to your needs.
On 20.05.2020 16:10, João Távora wrote:
> A non-appendix view would be: "I want to
> work on my Python, C++, Go program" and go do that, not
> caring about what was going on underneath at all, LSP, treesitter,
> CC-mode if-then-elses, you name it.
We won't be able to do this.
IIRC the preceding discussion, we won't be allowed to even install
language servers automatically.