On Sat, Nov 25, 2023, 13:01 Eli Zaretskii <
eliz@gnu.org> wrote:
> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 25 Nov 2023 12:39:22 +0000
> Cc: Niall Dooley <dooleyn@gmail.com>, 67442@debbugs.gnu.org
>
> On Sat, Nov 25, 2023, 11:09 Eli Zaretskii <eliz@gnu.org> wrote:
>
> > It supports surfacing Ruff diagnostics and providing Code Actions to
> > fix them, but is intended to be used alongside another Python LSP in
> > order to support features like navigation and autocompletion.
>
> What do you mean by "alongside"?
>
> João, does Eglot support such "alongside" servers?
>
> No. This is a feature on my to-do list, but alas I haven't had time to work on it.
OK, thanks. So AFAIU, we cannot install this change yet, right?
We can. If you read this patch it establishes ruff as an "alternative" ('eglot-alternative'), not as an "alongside" companion.
But just because we can doesn't mean we should. It's possible that the ruff server wasn't meant to be a full alternative to those other servers. Reading from its website hints ruff is mainly a linter, so it has a fraction of what other servers have
The proponents of this patch should argue in terms of ruff-only LSP support in python buffers. Maybe enough value that it's reasonable to install as-is, maybe not and we should wait for 'eglot-alongside'.
Or just wait for someone to code a flymake-ruff backend in python-mode.el. That seems much more promising way to get the intended ruff experience into Emacs.
There is also the common misconception (not sure if the case here) that if a server isn't mentioned in 'eglot-server-programs' directly then Eglot doesn't support it. And this is far from the truth: if 'ruff' is installed in a user's machine M-x eglot can easily be made to prompt for it. I've tried dozens of servers like that.
João