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

[João Távora]

Dmitry Gutov <address@hidden> writes:

> 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.

That has nothing to do with "integrated" as in IDE.  One presents a
patch to the author: if he doesn't want to participate in the scheme,
then he doesn't want to, period.  But it's very unlikely, since there's
no downside.  It's like not wanting to participate in, say, keybindings
or font-lock.  Even Alan agreed some lines of flymake stuff to go into
cc-mode.el after understanding they weren't going to explode.

>>> 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".

Let's stop this silliness.  I wrote: _not a problem of Eglot/LSP_.  How
could it be? If Emacs doesn't have rust-mode out of the box, you can't
use rust-mode out of the box, with copious apologies to users and their
perceptions and everyone other reader having to endure my statement of
the very obvious.

>>> 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.

They don't have to be familiar with the "LSP ecosystem" just a
particular program and its invocation.  The newbiest of users can help
there, it's trivial to setup.  You're totally off in this: Eglot
supports more than 20 servers (yes, it supports more than are listed)
and the majority most of them work very nicely without any
customization.

>>> 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.

Yes, so you're making my point.  The things that go into the major mode
are usually minimal, usually little more than setting the value of
`eglot-server-program`. But those minimal bits do belong there.

>>> 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?

Eglot supports LSP, the Language Server Protocol, a mechanism whereby
editors don't have to care about the specifics details of a language.
We don't support language specific extensions, but we do support an API
for major-modes or users to enter into that business if they can't
select a better server or work to improve the protocol.  If you have a
specific thing would like to be able to do, I'm more than open to hear
about it, but shoving some lsp-mode files here to make me hunt its bloat
for dubious language-specific features of servers that I don't use is
not my idea of fun.

Eglot was designed specifically with certain ideal of Emacs in mind, one
you're totally free not to agree with.  Goes like this: major modes
customize little bits of minor modes and other infrastrcuture to assist
them in their work.  I see Eglot as LSP infrastructure much as
font-lock, imenu, syntax, flymake, you name it.  I will only do the
<thing>-<language>.el dance as a last resort, (cf. flymake-cc.el), when
it's hard to communicate with the major mode author.  But my starting
position assumes it won't be difficult to do so, because that's how my
ideal of Emacs is: open, collaborative and proven good stuff goes where
it needs to go.

The fact that Eglot started of as a separate package was purely
intrumental: I needed to test some ideas beforehand and convince myself
and the world that such an approach was possible.  I'm sorry if you're
not convinced (or only half-convinced).  I think it would help if you
actually tried it a bit and collected some actual problems or ideas.

> I'm not saying it can't possibly work, just that it looks suboptimal,
> given existing development trends and areas of responsibility.
  
Sorry, but that sounds a bit like generic managerial talk, very little
juice there.  Bring real problems to the table.  Bring something of the
form: "I was trying to this and that with eglot.el, but then this dragon
appeared, how do I slay him?".  Bring that to the issue tracker.

I don't think your worries about major-mode authors being burdened, or
too many emacs-diffs emails, or confused users, hold much water,
frankly.  The idea is for Emacs 28 to have good LSP support in the core,
and I'm encouraged to see some support for that idea.  Incidentally,
there are much larger challenges with LSP such as arguing for a more
inclusive spec -- which is the whole point of LSP.  Perhaps you could
cast your energy and theoretical concerns in that direction.

I'm signing off this sub-thread, there's nothing more to add here, you
can have the last words/make your final arguments.

João