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: Tue, 19 May 2020 15:11:23 +0100

On Sun, May 17, 2020 at 2:38 PM Dmitry Gutov <address@hidden> 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.

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

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.

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

3. If Eglot were in the core, again, no need for the centralized stuff
currently living in eglot-server-programs.  Also, major modes in the
core can affect Eglot's LSP interfaces via stronger coupling techniques,
such as adding methods to generic functions.  Besides major modes,
other tools than build on some LSP basics, such as an LSP-enabled
spell checker could be built.

In general, I'm intent on describing a pattern here: there's a very
good reason for functionality that can be seen as infrastructure
to be in the core.  At least as long as the users of such infrastructure
(which are often, but not always, major mdoes) also live in the core.

So the solution is to move the infrastructure bits to the core, or
move every major mode to GNU 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.

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

João



reply via email to

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