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

[Dmitry Gutov]

On 20.05.2020 19:41, João Távora wrote:
> Dmitry Gutov <address@hidden> writes:
>
> > > Right. That part is optional, as I wrote.
> > So it's actually off topic for this discussion.
>
> AFAIU we've been talking about modularity for quite a while, so it's
> really very much on topic that we discuss ways to modularize software
> and the possibilities that opens.

The topic is core vs ELPA.

> > Fix your completion function to honor the c-a-p-f contract (at least
> > when it matters).
>
> 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.

> > I wouldn't say no to a milk run, however.
>
> Skimmed, full-fat, goat's, what do you want?

Goat milk is the best.

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

> > So IIUC you want to delegate that to both major modes that are
> > available for Rust currently. And if the one installed by a user will
> > fail to do that (or do it correctly), and the user files a report with
> > us, we will shrug and forward them to deal with the authors of their
> > major mode (helpfully explaining how to determine what major mode they
> > are currently using).
>
> > Is that the idea?
>
> More or less, yes. That's very much what I do already when the problem
> 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.

You probably see what I'm getting at.

> 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 don't recall: if Flyspell extensible? Like Flymake, for instance. If
> > >      it is, this seems to call for an eglot-flyspell plugin.
> > > I don't think it is. And extensibility is not a binary thing,
> > > depends on the API. Oftentimes rewriting is better. Flymake was
> > > extensible, before the rewrite.
> > 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.