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

[Dmitry Gutov]

On 23.05.2020 03:48, João Távora wrote:

> > > 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.
> >
> > It's less "integrated" than what that other mode is doing.
>
> I don't see how.  We must be talking about different things.  I'm
> talking Emacs -Q, C-x C-f foo.xxx RET and xxx-mode kicks in, sets up and
> maybe even starts Eglot.  For that to work, xxx-mdoe has to be in core,
> otherwise you need M-x package-install xxx-mode

*And* you need the author of xxx-mode to participate in the scheme.

> > So worst case scenario, people will point out that Emacs core has
> > released something not entirely complete while there is a package with
> > all batteries included.
>
> You're saying this becasue rust-mode isn't in the core and/or GNU ELPA?
> Than it's not a problem of Eglot/LSP at all.

I'm talking about user perception, you respond with "not a problem".

All right then.

> > Again, examples of much simpler programs. And historically stable. And
> > Rubocop has its own, well-documented configuration interface (text
> > file) that's expected to be edited by users.
>
> Don't see any reson why an LSP server would be some kind of second-grade
> delinquent program.

I integrated Rubocop because I'm familiar with it, just like almost 
every Rubyist. I don't imagine we could say the same about all major 
mode authors and the LSP ecosystem.

> > And of every major mode author making the effort to familiarize
> > themselves with this stuff, apparently.
>
> Same with font-lock and imenu and eldoc and forward-sexp-function.  Mode
> authors needn't familizarize themselves with the protocol, only in some
> cases with the server program they're setting up.  Like rubocop.

The font-lock, imenu, eldoc and f-s-f provide extension points where the 
extensions can basically indulge in unbounded levels of creativity, 
support various languages, frameworks, libraries, and so on.

There's literally no possibility to contain that all in a file shipped 
with Emacs. *And* a significant portion of these extensions out there 
requires knowledge and experience that the authors of these extension 
points do not possess. They only needed to create flexibility.

The situation with LSP is different: the total creativity is limited by 
the LSP protocol, and the extensions will be pertaining to LSP server 
settings, if I understand your examples so far.

> > You might be forgetting that Eglot doesn't exactly support _all_ the
> > features that languages servers offer. At least, that's my impression
> > of your answer to the question about refactoring actions.
>
> Eglot supports refactoring actions.  Commands and renames and stuff . I
> don't know what where you want to go with this.  Give an example.  If
> Eglot doesn't support something we can add it.  LSP works by
> "capability", what capability are you exactly referring to?  And not all
> servers support the same capabilities.

What about Java development? Does Eglot provide all capabilities 
included in the "LSP Java commands" section here, in some shape or form?

https://github.com/emacs-lsp/lsp-java/#supported-commands

Here's some other stuff that seems unlikely to be in the spec.

FSharp-specific settings and notifications: 
https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-fsharp.el

Metals specific notifications and commands: 
https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-metals.el

> Else we're just
speaking in the abstract, you trying to convince me that something
somewhere someday is not going to work.

I'm not saying it can't possibly work, just that it looks suboptimal, 
given existing development trends and areas of responsibility.

And I'm not crazy about the increased coupling to major modes.