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

[João Távora]

Dmitry Gutov <address@hidden> writes:

> I'm not sure how splitting out a "core" package would help if the
> "full" version depends on it, actually. Surely you are going to
> support the users of the "full" version as well? And they will have a
> longer list in `company-backends' by default.

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.

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

> For example, "solitude".

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

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

Also, there's a very good thing in Emacs called `define-derived-mode`.
And lots of other options.

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

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

> It was more of a weak, exasperated laugh. We couldn't evict Alan even
> if we wanted: CC Mode is a beast, and C++ is difficult enough to
> support that there haven't been any real alternatives, I think, ever.
>
> sm-c-mode in GNU ELPA is a cute experiment that supports only a
> fraction of its features. Even for C, IIRC.

But there is TreeSitter.  And LSP.  And probably more parser solutions.
Even Semantic has a parser generator which I dont' think has been
sufficiently explored.

Anyway, C++ is just one language among many.

> From what I see it there, someone could/should make an RLS-specific
> plugin for Eglot.

No, that's not my view at all.  That's precisely what I don't like about
lsp-mode.

> Not sure how major modes would help. There are several language
> servers for Rust, after all.

So the major mode chooses the best one.  Or it can even decide on a
preference order between multiple servers.  Up to the
author/maintainers.

>> See also the `;;; API (WORK-IN-PROGRESS!)` section in eglot.el. Every
>> generic function that takes a server as an argument is a candidate
>> for major mode tweaking.
>
> Like generic functions. Suspicious on the idea of major mode specification.

¯\_(ツ)_/¯

>> 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.  Actually
CEDET is, but noone knows how that works.

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

>>>> And do I really have to download clangd and xcode-specific code
>>>> to my machine.
>>> This pertaining to..?
>> Company.  Did I put it out of context? Sorry.
>
> 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.

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

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

>> PS: this discussion is getting looong.
> Yup.
Yup, yup, trying to wrap up.