From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#62694: 30.0.50; eglot-tests fails with recent pylsp Date: Sun, 09 Apr 2023 19:17:52 +0100 Message-ID: <87a5zgor73.fsf@gmail.com> References: <87sfddibcn.fsf@gmx.de> <87o7o1tfvc.fsf@gmx.de> <87ile5gv0c.fsf@tcd.ie> <874jppb388.fsf@tcd.ie> <87ttxpf725.fsf@gmail.com> <87pm8dcbr7.fsf@gmx.de> <87o7nxf44b.fsf@gmail.com> <87lej1ca2s.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="25875"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Basil Contovounesios , 62694@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 09 20:16:21 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1plZaP-0006co-9o for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 09 Apr 2023 20:16:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1plZaA-0000Xk-Dr; Sun, 09 Apr 2023 14:16:06 -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 1plZa8-0000Wl-7s for bug-gnu-emacs@gnu.org; Sun, 09 Apr 2023 14:16:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1plZa6-0000Dh-Hl for bug-gnu-emacs@gnu.org; Sun, 09 Apr 2023 14:16:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1plZa5-0002pt-TG for bug-gnu-emacs@gnu.org; Sun, 09 Apr 2023 14:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Apr 2023 18:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62694 X-GNU-PR-Package: emacs Original-Received: via spool by 62694-submit@debbugs.gnu.org id=B62694.168106415610888 (code B ref 62694); Sun, 09 Apr 2023 18:16:01 +0000 Original-Received: (at 62694) by debbugs.gnu.org; 9 Apr 2023 18:15:56 +0000 Original-Received: from localhost ([127.0.0.1]:33642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1plZZz-0002pY-Mt for submit@debbugs.gnu.org; Sun, 09 Apr 2023 14:15:56 -0400 Original-Received: from mail-wr1-f41.google.com ([209.85.221.41]:45000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1plZZy-0002pL-Dl for 62694@debbugs.gnu.org; Sun, 09 Apr 2023 14:15:55 -0400 Original-Received: by mail-wr1-f41.google.com with SMTP id d9so2923422wrb.11 for <62694@debbugs.gnu.org>; Sun, 09 Apr 2023 11:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681064148; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1VC3Tyj/LmiZRxSh+uYIjoIy5Y02vcPsoPaNzxJAf4s=; b=POZAA/JAxrP1LOuM6j6xXjvOiUlBJPb/p6ezOo1OPwN0U+5qdEVoze1vZw86seOYgN OmUkG/ebeFn2JPfQAoauNEe+iVmAw/Sb4urRH6AEdNeNJcTacnD1NK71bqxwMxyPFodY 6ZLqFT6rhBWle2/c/7EhMTEddGbHhvNg7eiK9lxlHhP1wrQ6GvE0hXpdNARTZKe5/bdm 6Iym/iFfQCZ5W0ky0HgrnO0ARqibz9fnxUB7Y136bem7Fl7y7ei55pdwrvi7n0YChf6b Uqb3F+GRm8wbRAdsHyDob/SS37l9wp73ogK9FnEWGp7+niJoHCv1tHYD26hn5qDRJ4O1 aeVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681064148; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1VC3Tyj/LmiZRxSh+uYIjoIy5Y02vcPsoPaNzxJAf4s=; b=Lm9ReSvASwAQ+hziDZ8Rlyhqgcz0U4nNQlLZ3/vdBtp2tDzGY4HSy0EZFmWWFPDURH FeMZ0CsKr5xCoidAmIY+AeoXJUkmiYO5Wj0PEvLLuelgYjZZJl9Sd3S8GKULBLBTAvCX /E6+fvn6OQHXwdgtV+S7yuaGkhLteOgj85jpOTmIsIJVcXhV6AE+t0JegxWURGONWa0s Ut+/aaMPCA2PVkLOOkDKSNjlCGIN5C8sI37+sueY3q4m1zUQKRRfECUrUPzhhg//bo3F DSSlKfKX/AXAAvOlYMzcsaDfEPlEQECGZsyvofbLsbLHtY70rfKEbXbjaJjn86mDdJso s9Qg== X-Gm-Message-State: AAQBX9eymxiXTex/uSl3bxcreZWdDBW0PxHCjQ3yVnPYNTP4uOl6iSuj ghgfXw6mLglgwuJa+IDleRp0eCz8bwY= X-Google-Smtp-Source: AKy350Z/U9QQ5DtUJWLVfotqygWCIdWyKKIHzLsx0chY8rtkTpw/4ABNn7qoO52IjVcBAZSkea0tRg== X-Received: by 2002:adf:da50:0:b0:2cc:4e58:f6d0 with SMTP id r16-20020adfda50000000b002cc4e58f6d0mr4996227wrl.54.1681064148002; Sun, 09 Apr 2023 11:15:48 -0700 (PDT) Original-Received: from krug (98.142.114.89.rev.vodafone.pt. [89.114.142.98]) by smtp.gmail.com with ESMTPSA id b14-20020adfde0e000000b002d1bfe3269esm9731448wrm.59.2023.04.09.11.15.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Apr 2023 11:15:47 -0700 (PDT) In-Reply-To: <87lej1ca2s.fsf@gmx.de> (Michael Albinus's message of "Sun, 09 Apr 2023 18:08:27 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259534 Archived-At: Michael Albinus writes: >>> I've shown you the Eglot traces for one test case on both Debian pylsp >>> (failed) and Fedora pylsp (succeeded). I still have no idea whether the >>> Debian flavour is inside the LSP specs or not. But if it returns >>> out-of-spec replies, I guess eglot should raise an Emacs error >>> indicating this fact. >> >> It's _not_ an out-of-spec reply. It's just a insuficient in-spec reply >> from a poorly installed or configured server. > > If it is an on-spec reply, eglot shall handle this. If there isn't > sufficient information in the reply, eglot shall err out with this > information. [I must admit I don't understand your use of "shall". Is this the German "soll", or is it really some kind of grave proclamation?] Let's see if I can put this misunderstanding to rest. There is a misunderstanding here. I hope I'm not going to be overly pedantic, here: I do this in good faith. First, Eglot is not the matter here, we're talking about eglot-tests.el. Now, for any software test to be effective in predicting if the thing under test is functioning correctly, there must be assumptions made. Sometimes they are called fixtures, the "fixed" thing you attach your system to. Here, the server is part of the fixture. We have to assume that the server will react in certain way when exposed to certain eglot-tests.el stimulae to be able to say things about eglot.el's correctness. If the pylsp server responds with no completions when completions should have been available -- as your log showed -- eglot-tests.el has to assume this is eglot.el's fault, which it very well might be if Eglot failed to properly communicate buffer changes or mangled some of its request or a million other things. This is exactly what these end-to-end tests are checking against: that the multiple Eglot actions leading up to completions are being taken correctly. In tests, we have to doubt something: we cannot doubt the fixture and the code all at once. The fixture is, by definition, beyond doubt. It's like if you were desining a sorting algorithm. You apply that sorting algorithm to a known randomly sorted list, check the first element to see if it's the smallest one indeed. You check with the function 'car'. If it's not the smallest element, will you doubt or algorithm or a misbehaving implementation of the function 'car'? How can you even know if you have a mischievous implementation of 'car'? It's certainly true that external language servers, being "external" to Emacs, are not as much under our control as the implementation of the car primitive. So they are not perfect fixtures. Someone suggested here that there should be an Emacs language server under our control, just like the 'car' is under our control. I agree. But this is an enormous task, so we have to surround ourselves with minimally stable fixtures. And pylsp is very reasonably stable when installed in the recommended fashion. Hopefully clangd is much better as a fixture (but it's not perfect). >> The point of these tests, as I've explained multiple times, is not to >> test the servers, rather eglot.el's particularly its interactions with >> other emacs facilities, such as xref, completion, flymake etc. Any >> server will do, as long as it is reasonably well-behaved and >> predictable. That's why I switched to clangd and all this discussion >> is moot now. > > It isn't only the tests. You cannot prevent that a curious user, with > the brand new Emacs 29 installed, reads the NEWS and knows there's > eglot. She installs the Debian pylsp server (because that's what Debian > offers), tries it, and fails. And you'll ghet a bug report. First, you speak as if Eglot is a brand new thing in Emacs 29. It's not. People have been using it since Emacs 26.3. But sure, and I get a zillion million of those (not for pylsp by the way). This is only natural: servers are very frequently buggy and users don't know about that unless they use a userr-facing client such as Eglot. So they, quite understandibly, report the problem to Eglot. I have to analyze them and refer the user to the server. It's happened so many times I've lost count. The server maintainer discusses the issue with me and we come to conclusion as to where the bug lies. There's nothing else I can do about that. LSP server bugs are super-frequent. But here, it's not even a pylsp bug. It's a Debian packaging bug, by all acounts. But 0 users except for you have reported bugs in the pylsp server, in the 5 years that Eglot has existed. And if they had, I really doubt they would have so obstinately resisted the tip to install pylsp in the recommeded way or report this prolem to the Debian packagers, at least to get their input on this matter. >>> Based on this fact, you could always catch this specific error in the >>> tests, and say that the server is not suited. Whether you shall skip >>> or err out the test then is something else; until now it isn't obvious >>> that a failed eglot test is due to the (possible) server misbehavior, >>> or due to an eglot error. At least this information should be shown. >> >> It's impossible to know that. You can design perfectly in-spec naughty >> servers breaking all of eglot tests. > > Eglot shall fail the gracefully. The error messages I have seen so far > don't tell me anything. These are end-to-end tests. What better messages would you like me to put there? Just submit a patch. >> Or you can follow Eglot's maintainer advice to install versions of >> servers known to be working correctly. Heroically complexifying Eglot >> to detect misbehaving servers is a completely futile exercise. > > That's an illusion. People don't follow advices, people don't read > manuals. Believe me with 20+ years of Tramp experience, 40+ years > experience in developing and maintaining large projects. Well, you certainly don't, that's for sure. Jo=C3=A3o