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

[arthur miller <arthur.miller@live.com>]

[-- Attachment #1: Type: text/plain, Size: 6362 bytes --]

Lately, you have talked so much about inclusion, Elpa, Melpa,  making Emacs easier, what new functionality would be useful, etc.

But nobody talks about excluding stuff. One of Emacs complexities is that there are so many different paths to accomplish same thing. Autocomplete - Company, Helm-Ivy, semantic-lsp, different spellcheckers, skeleton-yasnippet, etc. While I am all for democracy and freedom and Emacs extensible nature is perfect ground for growing diversity, it might not always be that too many choices equal freedom.

Maybe it could benefit if you clean up Emacs of some old cruft, and maybe replace some old for new. I mean be brave enough to make a choice and be vise enough to leave options for those who prefer differ path.

There will always be someone who disagrees with any choice of package you make and in general with any choice you made. If you wish to please everyone you will never please anyone. And whatever choices you make today will probably change in 40 years to come anyway, so it is not like change is written in stone forever.


Skickat från min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: Dmitry Gutov <dgutov@yandex.ru>
Datum: 2020-05-19 17:25 (GMT+01:00)
Till: João Távora <joaotavora@gmail.com>
Kopia: Richard Stallman <rms@gnu.org>, joostkremers@fastmail.fm, emacs-devel <Emacs-devel@gnu.org>, "Alfred M. Szmidt" <ams@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 조성빈 <pcr910303@icloud.com>, Eli Zaretskii <eliz@gnu.org>, Phillip Lord <phillip.lord@russet.org.uk>
Ämne: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

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.


[-- Attachment #2: Type: text/html, Size: 8016 bytes --]