[Top][All Lists]

[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: Dmitry Gutov
Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
Date: Tue, 19 May 2020 22:38:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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:


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*

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

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

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.

reply via email to

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