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

[João Távora]

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.

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

Better yet, M-x report-emacs-bug, put "eglot" somewhere in the title,
and make sure you CC me in the receipt from debbugs (yes I know you know
how to do these things, just testing out a new section in the README.md
;-)  )

> I wouldn't say no to a milk run, however.

Skimmed, full-fat, goat's, what do you want?

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

>> Anyway, major modes in emacs are about loading one file, or 
>> requiring one feature and having everything set up, even if not
>> enabled immediately. In my opinion.
>
> Another problem with that idea is that it hints that major modes might
> stop to work properly in the absence of LSP. Or a least some of their 
> major functions.

I mean, major modes can _leverage_ LSP: if it's not there they do
something best-effortish.  Modes can leverage multiple things: up to the
mode.

> That aside, going back to
> https://github.com/joaotavora/eglot/issues/363, it seems to mention
> some extra configuration that is needed to be done for integration for
> RLS. And it's fiddly, and the format how to specify it is non-obvious.

That's a question of interfaces and documentations.  The format to
configure servers in some parts is "free", or "server dependent".  It's
the major mode that must know what is reasonable to provide to the
server that it is configururing.

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

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

João