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

Previous Next

Full log

Message #23 received at 79290 <at> debbugs.gnu.org (full text, mbox):

From: Doug Davis <ddavis <at> ddavis.io>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Felician Nemeth <felician.nemeth <at> gmail.com>,
 79290 <at> debbugs.gnu.org
Subject: Re: bug#79290: 30.2; eglot-alternatives doesn't support re-use of
 same program with different subcommands
Date: Sun, 24 Aug 2025 14:26:14 -0500

João Távora <joaotavora <at> gmail.com> writes:

> On Sat, Aug 23, 2025 at 6:38 PM Doug Davis <ddavis <at> ddavis.io> 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.

I can't argue with your point above (the pyvenv package solves this very
well, I've used it for many years). I've typically leaned on
.dir-locals.el or some function of my own (added to python mode hook)
that finds and activates a virtualenv in a project. Using uv to launch
an LSP server with `uv run <program>` just eliminates the need to worry
about virtualenvs completely (uv automatically handles all venv
creation/discovery).

> 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

IMO the core of the issue is that completing-read is getting a list of
programs, where each the program is resolved from (car a) where a is
typically the entries of a list like:

  '(("uv" "run" "program1")
    ("uv" "run" "program2")
    ("program3"))

So then the list passed to completing-read is '("uv" "uv" "program3")

And completing-read just ignores repeated input; e.g.

  (completing-read "pick:" '("uv" "uv" "program3") ...)

will only show "uv" and "program3"; so my diff from my previous reply
just concats the lists to make the completing-read call:

  (completing-read "pick:" '("uv run program1"
                             "uv run program2"
                             "program3") ...)

that is, with all unique entries.

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

I'd completely understand if this QOL change is beyond the scope of some
other larger work on eglot (also, I've personally never used C-u M-x
eglot, but it appears to work fine with the diff from my previous reply,
which has been working fine for me and my plain M-x eglot usage).

cheers
Doug

>
> João
> [4. text/x-emacs-lisp; zenv.el]...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.