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

["João Távora" <joaotavora@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> 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.

Sorry to have drifted the party line.  Anyway, my point, for your
consideration: "I wish Company could be modularized.  Among other
reasons so that a part of it could enter core and be more integrated
there".

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

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

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

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

>> 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.  Again, nothing to do with LSP.  And again,
you're putting the cart of the apocalypse way in front of the horses of
the apocalypse.

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

João