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

[Dmitry Gutov]

On 19.05.2020 20:28, João Távora 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.

Maybe you could provide better arguments. Because I understand the idea, 
but the details of the argument don't convince me, so far.

If you just argued that it would be good to have a completion popup in 
the core, and _enabled by default_, I would have nothing to say against 
that.

> > 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 a different point than you originally made.

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

Because I have other things on my list, and because supporting different 
versions of the same package is not as fun as someone might expect.

Also, you ask for things that would make life easier for you, but when I 
ask you to play by the rules of the framework, you reserve your choice 
to just go the most convenient route.

> Anyway, after my fix, I've finally got them to update the webpage:
>
> https://github.com/llvm/clangd-www/pull/1/commits/a328d8e92eb05b8e62cd0973b592d6b48278c23d

That's a good news.

Anyway, I'm considering removing company-clang by default (and some 
other backends as well) after some upcoming release of company.

To do that, and to avoid confusing some of the users, I'd have to create 
some instructions on what C/C++ developers should use and in what cases.

If you have free time for some documentation writing, help welcome.

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

What would they use in it?

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

Um, that's unlikely to play a big role.

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

If there is something existing code in Emacs can tap into in the "new 
part", I don't have anything 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.

As far as Yasnippet is concerned, I'm not arguing to change things. You are.

I'm arguing the current situation is pretty good, and not without reasons.

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

Okay then, we'll go ahead and make everything into GNU ELPA packages.

And /my plan/ will be two steps closer to fruition.

*evil laugh*

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

Could you please avoid referring to general statements by Eli until you 
actually discuss some particulars?

"Let's provide features we can provide" as as sensible as it is 
noncommittal.

> If Alan doesn't want to, then we'll make another C mode,

*insert another kind of laugh here*

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

Yes, there are many ways to try to skin this particular feline. Some of 
them more optimal than others.

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

If we add every [important or fast-moving] core package to GNU ELPA, 
that could solve some problems indeed.

Mainly leaving organizational issues, like increasing the diffs mailing 
list traffic, the bug tracker load, and so on, the more packages we take 
in. And increasing the core's risks and commitments in unfortunate cases 
where the original authors leave.

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

I asked, last time you mentioned this.

> Anyway, see eglot.el.  It has some, though I've been quite conservative,
> again, precisely _because_ that code doesn't belong in eglot.el.

Could you mention some symbol to search for, at least?

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

That could be true. But if the Eglot team are best-positioned to write 
that code, and to maintain it, you'll be the ones to do it anyway. Then 
why split it across files, move it to major modes, etc?

Furthermore, if some necessary setup will be performed in CC Mode, then 
alternative C modes, if they ever appear, will harder time making use of 
it. I'm not sure if we'll have this particular problem, but alternative 
major modes have been created for other languages. Rust, for instance.

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

This pertaining to..?

> > > 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'm just saying it's not an argument in favor of either of the options.

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

In theory, your statement makes sense. But I don't see any solid 
examples so far, as pertaining to packages under discussion. And only by 
considering examples in detail we can derive good rules.

> Both approaches are defensible, of course.
> But a mixed approach will tend to limp.

This, however, is something good-sounding, but just as likely wrong as 
it is right. We could use some principles, however.

Yes, I want Emacs to be modular, and I'm not the only one. But the 
degree of modularity, and the division lines, all should be driven by 
practical considerations.

Do you like the current monolith? Are you sure the current architecture 
is good, and gives appropriate incentives to the authors?

Do you like message-mode (as essential feature) still being a part of 
Gnus, a big specialized application, after all these years, and 
depending on its other code?

Do you like that Org is just its own microcosm, and basically never 
extracts features?

Do you like all the references to tramp- functions outside of its 
implementation?

I don't want to criticize anyone in particular (we're all volunteers 
here), but some clearer distinction between infrastructure and 
applications could do good.

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

Eli asked why we never followed up on our "promises" to consider some 
packages for the core which we put into GNU ELPA. I explained that those 
packages likely didn't need that anyway. This is where this line of 
discussion came from.