From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Eglot tests on EMBA Date: Fri, 31 Mar 2023 14:35:43 +0100 Message-ID: References: <87y1nyi5cq.fsf@gmx.de> <87tty3eide.fsf@gmx.de> <878rfddxeu.fsf@gmx.de> <87zg7tce2p.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16576"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 31 15:36:21 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1piEvV-00048f-FA for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Mar 2023 15:36:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1piEv9-0001k3-E6; Fri, 31 Mar 2023 09:35:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1piEv7-0001jD-G1 for emacs-devel@gnu.org; Fri, 31 Mar 2023 09:35:57 -0400 Original-Received: from mail-il1-x136.google.com ([2607:f8b0:4864:20::136]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1piEv5-0001kp-NG for emacs-devel@gnu.org; Fri, 31 Mar 2023 09:35:57 -0400 Original-Received: by mail-il1-x136.google.com with SMTP id o12so6490711ilh.13 for ; Fri, 31 Mar 2023 06:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680269754; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=diXt82LhJmcRfwOxmIMiRDr5HZEjj6jfNAZBYH9aUcQ=; b=WkuDZcmdnzfamT6uzw6fP9WbOtftgytgzPxhAIHOlitsCWNk5dmiqD/lzmV5HoVu8J kN49/OeMEGh2s7fw4vTGQfHbzgJoo4fckGgn9paRCHltLmMGriNinQ4YCKd4umiabQzK jBkj14UybOQIbl8s4JIzk8E8PhqS20JNDekvzh6oPKY/VhUV6PQpYOjoxh7Ub8Bf+HGi 5JkNvtqRLI0O7cQpm6TYNRHl9eGEq0uf33nH5h0qPFDmpoXg2pfHQoLKfY9XKnacxjJV 7eqASmTjfMHVG1BuMBpgrNvXQmtUat0gws0oJOwhGMZrzZ3zGHJUG+GKIuEdgc2BTF/d aoGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680269754; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=diXt82LhJmcRfwOxmIMiRDr5HZEjj6jfNAZBYH9aUcQ=; b=UFXg1pTuUB5pLhu6g6quUP29GChXIvX1XLZCFyrjC900+3M3qVX8isNhaUsZUAxXCR /wdIhDqSONBde/m+T9DJkEEmgNhhuP0sIEGYUG0l3tPu4S2JUpwYK5kJfXUyaTiQUaKy AsE9W8GSaEua5jAivm1Pe/QC2lwTTKbULvoyjygB6DXjf/Pp5t0yTwCD/s/3oRmoxVOT tZnxpHBreYxQnFd7AcuSmEHKpQYWGWHy/+7GjqEZXCXbBj4oWbgvcnR/9AsUdVc+NPMR IYCEBBQv0rF5JAHMlufrjliqshs0+X8a3pcoCjP5WbUvlS7ZTRvC5cqwK3lEt+RMPYyJ Nk+Q== X-Gm-Message-State: AAQBX9crPjf3skHEeJt1fHRvM3EmFvj6vjkvODSCJsJ571iOaKXEN6/7 RH5uM4Jk2ZmbG6PFBGVrlTpRe5zTSJU2zV/PXiPcUcrSRQ8= X-Google-Smtp-Source: AKy350ZChZ/wjHfiil+WZhtcRyZRRiHWMazPVNbuQcUYR8BxZogzq3yyKGvwegm26tKXAp1k+dmNVVUhyokEUJOnZkw= X-Received: by 2002:a92:cda3:0:b0:326:3f06:a0d7 with SMTP id g3-20020a92cda3000000b003263f06a0d7mr2779551ild.0.1680269754278; Fri, 31 Mar 2023 06:35:54 -0700 (PDT) In-Reply-To: <87zg7tce2p.fsf@gmx.de> Received-SPF: pass client-ip=2607:f8b0:4864:20::136; envelope-from=joaotavora@gmail.com; helo=mail-il1-x136.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304921 Archived-At: On Fri, Mar 31, 2023 at 1:14=E2=80=AFPM Michael Albinus wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > Hi Jo=C3=A3o, > > >> I'm not happy with this. EMBA installs a conservative list of software= ; > >> they shall be available as Debian bullseye package. > > > > Then you should complain to Debian and uninstall pylsp on EMBA is the > > meantime. > > Nothing to complain to Debian. They offer pylsp in the testing version; > we have simply decided not to use it. We use the stable version. > > >> Since Debian bullseye does not offer the package python3-pylsp (which > >> will be available with a later Debian release), I install on EMBA > >> python3-pyls. This shall be sufficient, because (according to > >> eglot-server-programs) "pyls" is supported. > >> > >> eglot-tests.el does not dertect this, it checks only for "pylsp". I > >> believe this shall be changed, > > > > No, it shan't :-) I'm not even sure how to do so portably. > > The most simple way would be > > --8<---------------cut here---------------start------------->8--- > (skip-unless (or (executable-find "pylsp") (executable-find "pyls"))) > --8<---------------cut here---------------end--------------->8--- > > But this is a sledge hammer approach I guess. Hmm, I'm confused. Why are we talking about 'pyls'? The test is for `pylsp`. It used to be for `pyls`, but now it's not. 'pyls' would probably have the same "provider" issue. My point is that I don't know how to ask the `pylsp` executable easily what "providers" it supports. pylsp --version doesn't hint at it. Maybe there is an easy way, but I don't know it. Maybe you meant these kinds of changes to eglot-tests.el? diff --git a/test/lisp/progmodes/eglot-tests.el b/test/lisp/progmodes/eglot-tests.el index b11ce942b7d..7215dc24b3e 100644 --- a/test/lisp/progmodes/eglot-tests.el +++ b/test/lisp/progmodes/eglot-tests.el @@ -570,7 +570,8 @@ eglot-test-non-unique-completions '(("project" . (("something.py" . "foo=3D1\nfoobar=3D2\nfoo")))) (with-current-buffer (eglot--find-file-noselect "project/something.py") - (should (eglot--tests-connect)) + (let ((eglot-server-programs '((python-mode . ("pylsp"))))) + (should (eglot--tests-connect))) (goto-char (point-max)) (completion-at-point)) ;; FIXME: `current-message' doesn't work here :-( This makes sense to me. It's an oversight that eglot-server-programs isn't restricted there like it is in other tests. To avoid hurting readability too much, this override could be an option to the eglot--with-fixture macro. > eglot-tests.el run for your environment. But there are people with other > environments (like Debian stable), which could errors running > eglot-tests.el. Yes, I understand, but I also doubt the size of the set intesecting people who have simplistic pylsp installations and people running the Emacs test suite. So I'm not very worried. And most people are using pyright these days anyway. > >> the check shall be for all alternatives > >> configured in eglot-server-programs. And not only for python, but also > >> for other languages. > > > > No, that's an immense amount of work and that's not what these > > tests are really for. People add stuff to eglot-server-programs > > liberally: it's a huge database now. I'm not crazy about that but > > is has always been the most fair practice to acommodate server > > preferences, and people seem like to see their favourite server at > > least represented there. > > Is it that hard to extract all relevant server executables for a given > major-mode, and iterate over them with executable-find? That's not hard, but what do you want to do with this information? What test do you want to design? I'm not following. Maybe I'm missing something. > > But some of these servers don't work, are deprecated, have > > inconsistent executable names on different platforms: it's > > a mess. Testing that is way beyond the scope of eglot-tests.el. > > In such a case, the test shall fail. And that would be OK, by this you > get feedback what doesn't work (given people write bug reports). I don't follow. What test fails? What would be considered "failure"? Not having all possible programs mentioned in `eglot-server-programs` installed? Can't be that, that's just tyranny :-) There's a lot of stuff in there. > > You may lobby for a eglot-server-program-tests.el instead, > > and I won't oppose it, but I personally don't have time for that, > > nor do I see a lot of value at the moment. > > > > eglot-tests.el is testing the server-agnostic Elisp logic in > > eglot.el -- Eglot _is_ server agnostic. We just happen to need > > someone speaking LSP to be able to exercise features. We could just > > as well have a (compliant) Elisp LSP server simulator and not worry > > about external language servers in eglot-tests.el at all. But that's = quite > > a bit of work. So some common installations of language servers are ne= eded. > > Sure, possible. I was just speaking about the given state of eglot-tests.= el. It's not super, because of these outside dependencies, but it's not a very bad state, I would say. It helped me catch a bug the other day :-) Jo=C3=A3o