emacs-devel
[Top][All Lists]
Advanced

[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: João Távora
Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
Date: Fri, 22 May 2020 15:32:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

Dmitry Gutov <address@hidden> writes:

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

I wasn't speaking of any particular one. I was telling how we work with
Eglot users that report server bugs to us.  You talked about
"footballing users" and how lsp-mode adress them "directly".  I assumed
that means they hack lsp-mode.el of lsp-foo.el to work around server
bugs, but I really have no idea.  In fact I don't know what we're
talking about anymore, I have to admit.

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

Drats, you've uncovered my master plan.  And I would have gotten away
with it too.

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

I wrote "develop".  And for the zillionth time: it _can_ be in ELPA too.

João



reply via email to

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