[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 20:20:37 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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

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

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.

reply via email to

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