emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]


From: João Távora
Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
Date: Sat, 23 May 2020 01:08:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

Dmitry Gutov <address@hidden> writes:

> I don't think that's what "integrated" means.

Why not? You find the Rust file, activate Eglot and it starts working.
Some major modes might even automate the second step, if it's cheap.  I
know people really like `eglot-ensure`, which that starts up a server
automatically.

> If the LSP settings are broken or outdated, however, the user are more
> likely to see that as Eglot being broken or obsolete.

I've explained this has specific to do with LSP.  It's the fact that you
rely on an external program.  Emacs does that all the time, with aspell,
shell programs, so nothing different here.  Aren't you ruby-mode
maintainer?  Doesn't it call the rubocop program?  Is it rotting
frequently?

>> Of course, as you know, the whole point of LSP to start with is to make
>> these obsolete.
> Some basic idea was like that, maybe. But then the reality
> intervened. And people value features more than stability.

I don't think it's very bad, the fact that only minor customization is
needed for a small set of servers means the idea is mostly solid.  It's
a question of good defaults, mostly.  And growing the protocol.

> And I'm fairly sure language servers will continue to provide their
> ad-hoc extensions because different languages have different needs.

Yes, true, but from these two years I've been seeing less and less of
that.  I bet a good majority of the servers Eglot supports work out of
the box, no special customization.  pyls, clangd, the javascript one,
and probably many of the other simpler ones. 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]