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

[João Távora]

On Tue, May 19, 2020 at 3:59 PM Dmitry Gutov <address@hidden> wrote:

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

I'm not arguing for it to go away, not at all.  I am arguing for a completion
tooltip in the core, much like icomplete, one that gets to integrate with
other pieces in the core.

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

In the Clangd webpage, a warning was issued to Eglot users:

"**company-clang is enabled by default**, and will interfere with clangd.
Disable it in `M-x customize-variable RET company-backends RET`."

This is clearly counter to Eglot's out-of-the-box experience, so I had
to override company-backends. Again, if you had left that brutal default
configuration out of the company package, I wouldn't have had to.
Really, even if just on github, why don't you create a `company-nocruft`
package that only has capf support?

Anyway, after my fix, I've finally got them to update the webpage:

https://github.com/llvm/clangd-www/pull/1/commits/a328d8e92eb05b8e62cd0973b592d6b48278c23d

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

What are you saying: major modes in the core _can't_.

And just because it was successful in GNU ELPA doesn't me it can't
be _more_ successful if developed in the core.  Below you say major
modes in the core aren't maintained: well, maybe _because_ they
can't tap into resources like Yasnippet.

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

One part can be developed in GNU ELPA, the other in the core.  BOTH
parts can be downloadable from GNU ELPA, nothing against that.

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

The lack of maintainers is not an argument for changing the place
where these things are maintained.  That's not magically going to
bring more maintainers.

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

No. You keep saying this, but if the major-mode is GNU ELPA :core
it's no problem.

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

Yes, supposing Alan wants to provide LSP features, yes. Eli has said
we wants features in CC mode that LSP is capable of supporting.

If Alan doesn't want to, then we'll make another C mode, maybe
resorting to LSP only or to TreeSitter or a mix of both. Or Alan
can come around.  Or make it opt-in.  Lots of options here.

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

Again, this fictional tragedy ignore the advent of :core GNU ELPA
packages.

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

Unless I missed something, you never asked.  Stefan asked off-list, and
I gave him examples.

Anyway, see eglot.el.  It has some, though I've been quite conservative,
again, precisely _because_ that code doesn't belong in eglot.el.
So you're describing the chicken and the egg.  Or look at the very large
amount of mode-specific code that lsp-mode.el.  It also doesn't belong
there.

And do I really have to download clangd and xcode-specific code
to my machine.

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

But it can be developed in the core and be downloaded from
GNU ELPA, as I keep saying.  The two things are completely
unrelated, thankfully.

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

This is the classic monolithic vs modular debate.  Emacs is mostly
monolithic, so unless it goes full modular, you're seriously
handicapping development of some stuff by demanding it sit
outside the core.  Both approaches are defensible, of course.
But a mixed approach will tend to limp.

Again, distribution and where the source code is kept is now mostly
orthogonal, thanks to :core packages.  The distribution is the thing
that's preventing the "discoverability" the supposed subject of
this debate.  Development is a different reality: we shouldn't
have distribution concerns hamper it.

João