[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: Wed, 20 May 2020 04:17:44 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 20.05.2020 03:59, João Távora wrote:

You're not following my idea.  I'm saying:

- make a company-base package that includes the basic company stuff like
   the nice tooltip code and what is now company-capf. (Maybe also move
   that to the core, why not?  :-)) Eglot would depend on just this.

- Make a company-clang, company-xcode, company-foo for users that want
   to use these things.

Then I would remove Eglot's overriding of company-backends, making you
happy in return.  If a user _also_ has company-clang installed and it
conflicts with company-capf, it's his problem, not Eglot's.

Again, note that none of this is predicated, or really affected, by company simply being in the core.

If it behaves sufficiently differently from company (as I recall you
were planning), you might want to pick a different name.

_That_ idea was a rewrite, something I've done in the past when I
haven't been able to convince the owner of the thing I want integrated.

You might have more luck after following certain requests by the said owner.

For example, "solitude".

Interesting, but doesn't really sell, does it? I prefer "freelance"
or "proletarian".

Proletarian sounds the best. Very solid and people-power'd.

Hm? They would define snippets for the programming they support.
Snippets that are active by default once you activate the major mode.
Or maybe they simply won't.
You might want to create a separate thread here with a vote and count
the major mode maintainers who are in. :-)

Major mode mantainers are all of us.

So you'll move information around but continue to keep it all up-to-date yourself, together with other Eglot developers?

I see your desire to offload some responsibility to major mode
authors, and I can sympathize with that. But if the people on the
other side don't pick it up (or pick it up but then forget), this
won't work. Especially with eglot-server-programs.

Again, major mode maintainers are all of us. I don't view code that
someone else authored as off-limits.  If there is a difference of
opinion, we bring it here and the matter usually resolved in the
interest of both parties.  If the major mode authors simply don't want
to have snippets or LSP or Flymake or treesitter-vapourware.el support,
then there's nothing we can do except making an alternate major mode.

I'm not even talking about people rejecting such changes. Only about that someone would need to make them, and to maintain them thereafter.

Not everybody might agree, though. You might notice that there's still
no cc-mode package in there.

I detect a hint of obsession with cc-mode.  Not good, not good :-)

Just a friendly warning, from a fellow revolutionary to another.

to change that fundamental property, you are fighting Emacs, in my
opinion.  I want to find a Python file and start working in the best
The only major mode that integrates with xref is emacs-lisp-mode,
AFAIK (ok, and a couple of derivatives of it). All other integrations
are in minor modes. That could probably tell you something.

It tells me those major modes don't have access to the tools that
provide code navigation, because they're not in the core.

Or that the tooling is decoupled from the major mode definition.

CEDET is, but noone knows how that works.

There is one Indian guy who keeps posting videos of new improvements he made, but for some reason isn't hurrying to upstream the changes.

By the way this reminds me of a Medium thing I read this week
where one users was fed up with VsCode asking to install packages
for typing an Hello World in C++.
One user indeed.

With a meme-laden Medium account, and lots of fanboys, come on! That has
to count!

Then he speaks for all of us, naturally.

I still don't understand what this is about. I don't have clangd or
any xcode stuff on my machine, and I develop Company.

Sorry, not clangd, I meant clang.  I mean I _certainly_ don't have xcode
but I have a file called company-xcode.el because i installed Company
with code that I suppose is for xcode.  Not only that company-xcode is
in the default value of company-backends.

Yeah, that one will also have to go.

But you wouldn't rewrite Flyspell on rely on LSP only. It would still
have to be extensible/flexible/open. So how would Eglot's presence

Eglot contains much of the code that would make it possible to rewrite
Flyspell to rely on LSP, even if as an alternative.

I don't recall: if Flyspell extensible? Like Flymake, for instance. If it is, this seems to call for an eglot-flyspell plugin.

So you wouldn't even agree that it would make a lot of sense to move
Org to ELPA? It's not even developed here.

If Org is somehow a library helpful to other things in the core,
no.  Otherwise yes, if indeed it is not developed here (in emacs.git)

At least we're somewhat compatible on the basics.

reply via email to

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