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

[Dmitry Gutov <dgutov@yandex.ru>]

On 19.05.2020 17:11, João Távora wrote:
> On Sun, May 17, 2020 at 2:38 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
>> I would like to point out, as an author of several packages, that in my
>> experience having a package in ELPA is _better_ than having it in the core.
> 
> I know you like to develop on GitHub, and I'm not going to argue that:
> it is a completely separate discussion.

Indeed. That's why I was arguing about different things, rather than how 
nice it is to be able to use a different hosting and bug tracker.

> I disagree on specific technical reasons that IMO don't get enough attention:

Below, you are arguing about two specific packages. I didn't say that 
_no_ packages should be in the core, however. Just that for most of them 
there is not much additional benefit from that.

But we can discuss these examples, too.

> 1. If Company were in the core, you could have major modes in
> the core or elsewhere setting up the desired completion strategy or
> strategies.  I.e. instead of  having central database of
> `company-backends` that packages like Eglot have to override to behave
> sanely, you could have a buffer-local  `company-backend` instead. You c
> ould continue to develop the specific eclim, clang, xcode, etc backends
> on GitHub, but you wouldn't "force" them on people that don't use them.

Major modes already define c-a-p-f, we have a frontend-agnostic API for 
that. On top of it, however, Company provides finer-grained controls for 
the users, which can't be decided by major modes.

I don't think 'M-x completion-at-point' can be realistically expected to 
go away in any near future, so it doesn't seem like some tighter 
integration with major modes is on the table (and I don't know what it 
would look like anyway).

As for Eglot, it seems to successfully do what you want here with no 
extra boilerplate. The only problem I see there is breaking some users' 
existing configurations.

> 2. If Yasnippet were in the core, again, no need for the centralized
> database of snippets: major modes define their snippets.  Other tools
> can use the snippet-defining infrastructure without eating all that
> João-the-ten-years-ago newbie cruft. But even with yasnippet.el, it
> is possible (though not ideal: Stefan once convinced me to rewrite it
> which I did to 90% in a so-called snippet.el -- but there's still the
> 10% missing).

Yasnippet has been wildly successful without all that. It's the #1 
standard snippet solution and format for Emacs. It's in GNU ELPA, 
everybody can use and depend on it.

About "newbie cruft", how will that go away without somebody rewriting 
yasnippet's code? And when they do, the result can sit in GNU ELPA as well.

Finally, the only snippet collections I still see maintained are being 
done by third-party developers. If the major mode authors (BTW, how many 
are actively maintaining major modes in the core?) wanted to also add 
snippet collections, they'd have already done so.

And even if they do the new snippets will only reach the users once 
every 2 years. (facepalm emoji)

> 3. If Eglot were in the core, again, no need for the centralized stuff
> currently living in eglot-server-programs.

Right. So CC Mode will define which completion server will be used by 
Eglot? Really?

And suppose major mode authors even decide to take up that 
responsibility, the LSP field moves much faster than Emacs these days. 
Six month after Emacs 27 is released, another LSP server for C++ falls 
out of fashion and stops being developed, and Emacs users will stay with 
outdated settings until the next release. Or until their distro switches 
to Emacs 28, actually, which can be another several years.

> Also, major modes in the
> core can affect Eglot's LSP interfaces via stronger coupling techniques,
> such as adding methods to generic functions.

You still never gave an example for that.

> Besides major modes,
> other tools than build on some LSP basics, such as an LSP-enabled
> spell checker could be built.

Yes it can. Anything stops it from being in ELPA?

> Also, I want to note, again, that even if Company, snippet.el and
> Eglot  were in the core, they could still _also_ be available
> for download via GNU ELPA.

I also noted that later.

>> The exception to that rule is more or less cases where the package is
>> not only added but also enabled by default.
> 
> I've argued that that's not the only exception.

I'd argue if we call something "infrastructure", then it should either 
be enabled by default, or used by other packages, or otherwise have a 
necessary stronger coupling to other code. This is a fairly high barrier.