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

[Dmitry Gutov]

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

> Actually
> 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
> > help?
>
> 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.