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

[Dmitry Gutov]

On 22.05.2020 13:49, João Távora wrote:

> > > It _is_ honouring it.  You want to revisit that, fine.  Open an
> > > issue in Eglot's bug tracker.
> > We've been over this a dozen times, on the issue tracker, in the
> > commit comments, etc. If you just want to give me the runaround, it's
> > on you.
>
> No.  Burden of proof is on the accuser.  Open new issue, start a thread,
> continue an existing one, etc.  Also: "The topic is core vs ELPA."

You've made my point.

> > > > >         not even talking about people rejecting such changes. Only about
> > > > >       that someone would need to make them, and to maintain them thereafter.
> > > > > Code doesn't really rot, especially when maintained in the same
> > > > > repository, built together and tested together.
> > > > I already explained how these settings get outdated.
> > > I missed it.  Can you point to it?
> > LSP servers come and go, settings get outdated. Like the one that was
> > mentioned in the RLS issue, I imagine.
>
> But that's the server's fault.> Hopefully, if major modes start relying
> on things, they should choose wisely and rely on some stable stuff.

Hopefully major modes don't.

> Just like ispell.el does to spelling programs.  I'm just saying
> generalities, because these things are general, they have nothing to do
> with LSP.  If one wants integration one has to integrate.

Did you just compare RLS to Aspell?

Relying on a "stable" program is fine until it doesn't do the job anymore.

> Seems like you don't want much integration.  Fine.  It's been said to be
> hard, and that's true.  But there _is_ an I in IDE, and it doesn't stand
> for "immense .emacs".

I never suggested to put the burden of configuring this on the user.

> > > is on the server side.  It's totally reasonable that the user comes to
> > > Eglot first, because that is the user-facing side. But the problem very
> > > often lies partially in the server, so we try to politely inform users
> > > of that and help them debug and/or collect information from Eglot's
> > > interfaces.
> > Meanwhile, lsp-mode developers will address similar reports directly,
> > without footballing the users.
>
> They regularly solve LSP server bugs in lsp-mode? Very bad idea. Relying
> on features is one thing, relying on bugs is another thing entirely.

Did that report concern a bug in a language server? It didn't look that 
way to me.

> > > Come to think of it, there's another argument for making Eglot
> > > "invisible" in the long run: the report would go directly to foo-mode's
> > > developers.
> >
> > I'm not sure this is how it's going to work. But suppose it will. And
> > suppose we only consider the major modes already in Emacs.
> >
> > If you decide to only field Debbugs issues that have "eglot" or "lsp"
> > in the name, you will miss said reports. Who's going to address them?
>
> I supose it'll work the same way we deal with a bug report about "my
> colours are all garbled" and it turns out to be about font-lock, which
> the user is oblivious to.

Offloading work to other contributors, I see.

> > > > Sounds like it should be. If so, my point stands.
> > > Doen't stand very strong though.  IIUC you're saying: first invest
> > > the effort in making Flyspell extensible specifically to support LSP,
> > > then develop its LSP backend in a different repo because modularity.
> > > That's not very enticing :-)
> > That's how it's going to have to work anyway.
>
> No. If there is LSP support in emacs.git and Flyspell is in emacs.git,
> you just develop in the same repo, emacs.git.

So what? Implementation-wise, it will be a plugin either way. Which 
would be just as easy to put in ELPA.