Subject: bug#79290: 30.2; eglot-alternatives doesn't support re-use of same program with different subcommands

From: João Távora <[email-masked]>
Date: Sun, 24 Aug 2025 13:40:41 +0100

On Sat, Aug 23, 2025 at 6:38 PM Doug Davis <[email-masked]> wrote:

> >> an invocation of M-x eglot will fail to show the second instance of
> >> using uv in the resulting list that appears to be passed on to
> >> `completing-read'. (Notice the repeated use of `uv run`
> >> https://docs.astral.sh/uv/reference/cli/#uv-run)
> >>
> >> more info: the benefit of using `uv run` unloads the burden of using
> >> emacs to property setup a virtual environment; uv automatically handles
> >> running the correct installation of the invoked subcommand.
> >
> > João, any comments or suggestions?
>

No many:

I run python servers myself and find that a simple handrolled "virtual
environment" helper that sets exec-path, process-environment, and PATH
works fine 99% of the time (if not 100% of the time) for my python
programming
needs, admittedly not very complex.  This includes eglot. Attached my
50-line
zenv.el in case is useful to anyone, though not  related to  this issue.

> Below is a patch on master that resolves
>
>   ("server-program" "arg1" "arg2")
>
> to appear as
>
>   "server-program arg1 arg2"
>
> in the completing read; just an idea
>

I don't fully understand the issue, but I don't have anything against
these quality-of-life patches if, and this is a big IF, they are small and
very well tested. I'm thinking about C-u M-x eglot, and other interactive
scenarios. eglot-server-program's syntax is crammed to the max
already.  Related to this, Philip K. had a good idea about
eglot-alternatives,
to make it "less functional", but I can't remember what it was exactly.

João