From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Date: Sat, 23 Oct 2021 22:50:00 +0200 Message-ID: References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <87o88w4al4.fsf@gmail.com> <87ilz444zy.fsf@gmail.com> <87k0jj35iz.fsf@gmail.com> <46AA4768-F628-49C5-A933-8ED43814CAC9@thornhill.no> <87ee9r2xwt.fsf@gmail.com> Reply-To: Theodor Thornhill 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="17665"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50244-done@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 23 22:52:52 2021 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 1meO0Z-0004MT-Hm for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Oct 2021 22:52:52 +0200 Original-Received: from localhost ([::1]:43690 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meO0Y-0005MQ-80 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Oct 2021 16:52:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58022) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meNyo-00042K-Oq for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 16:51:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54133) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1meNyo-0007fG-FY for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 16:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1meNyo-0007sE-8E for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 16:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Oct 2021 20:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs Original-Received: via spool by 50244-done@debbugs.gnu.org id=D50244.163502220830198 (code D ref 50244); Sat, 23 Oct 2021 20:51:02 +0000 Original-Received: (at 50244-done) by debbugs.gnu.org; 23 Oct 2021 20:50:08 +0000 Original-Received: from localhost ([127.0.0.1]:37446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meNxw-0007r0-4i for submit@debbugs.gnu.org; Sat, 23 Oct 2021 16:50:08 -0400 Original-Received: from out10.migadu.com ([46.105.121.227]:58975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meNxs-0007ql-I3 for 50244-done@debbugs.gnu.org; Sat, 23 Oct 2021 16:50:07 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1635022202; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PNWmLd0N10yCU6lOU4rZt3saF8bFa3teaC/zR1Xd6ZU=; b=LHy+Rtb0E7hIME7KDNXxRVbbwOakiB64PwZwd2thqgDDLO5eGoRN5szG0QwLntXsUWenIF O9eJyVUgTQLeUOdzVa5Ux+B38O3vzr/GSXMtJQaszrIqSg5I4zc7gJv2SztI6ze1pBY23e lKePqSAVWGdxomfkfet8UZXooKufoguylPiGLzjzAHqp34cYU5ezlc6QCiaBNpiTWYatIz Lx16ubqLhKq7XGSY2q0Gdwi658WVdhW8cqfTf6i+fr6INY4K92EK30WKqMAjTliP1eeeot Ctsj6SeOaSzyXvWeX3WKXxVbo8xsmFNQLge4/iTob666c9D1u6hBWlRBdk+QgQ== In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no 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" Xref: news.gmane.io gmane.emacs.bugs:218047 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Sat, Oct 23, 2021 at 8:22 PM Theodor Thornhill wro= te: >> (sent this mail some days ago, but the bug was archived, so not sure if >> it worked. Trying again. If this is only noise, then I'm sorry, but >> hopefully ok considering i found a typo in the old patch :)) > > No problem, and yes I got the other one. It's just I've been again > ompletely utterly busy so it'll be a while. I took the Flymake thing out > of my brain cache and it's going to take a while to get it back. > Didn't mean to rush things, we do have time :) >> I finally did get to test this out a little, and I seem to have hit some >> small snags I can't really understand. I'd love some pointers as to how >> to continue! >> (the patch I currently use is attached at the bottom) >> Ok, so what happens is: >> >> - There is no backend set on the list-only-diagnostics as for now, and I >> cannot for the life of me see how to set them, as it doesn't look like >> eglot itself sets it. Is there some reflection going on here that I >> have missed? > > No, I don't think so. Maybe I simply decided that no backend was > necessary? Is it? If it is, we might to add some mechanism so > that it is assigned. > I don't think a backend really is necessary anymore. I've been checking with more servers lately, and it seems to work better with some than with others. And especially elmls seems a little wonky here. >> - The function in question is riddled with fallbacks and failure >> checking. Are we sure we need all that? I see most of the commits >> relating to the range checking is from 2018, so they may not be >> relevant anymore? > > I'm not sure I follow here. I wouldn't delete any checks until I'm > sure they are doing nothing. 2018 or not, I do remember a lot of > servers providing very strange diagnostics and invalid ranges. > Yeah, I didn't remove any checks yet, and likely will not. I'm merely guessing that the lsp scene has settled a bit lately. >> - The diff as supplied appends the list-only-diagnostics just fine to >> the flymake buffer, but I believe since the backend isn't set, eglot >> doesn't report the proper diagnostics when I visit the file. I have >> to make a bogus edit to trigger the eglot-flymake-backend function. >> (This could just as well be some unrelated eglot/elmls issue...) > > Ah, this rings a bell. You're talking about visiting a file by clicking a > "list-only diagnostic" in the list, right? And then you wnat Flymake to > resume checking and replace them with "real" ones. Yes, might be > eglot/elmls issue, but usually there's not much we can do: some servers > are like that. > Yes, you are probably correct here.=20 > To keep things consistent we could remove the relevant list-only > diagnostics and re-report them via the normal mechanism if the server > is taking too long. > I'll look into this, and see if I can find a solution for this. > Do you understand this idea? The user wouldn't, in principle, be able to > tell that the freshly annotated diagnostics weren't collected just now > when he visited the buffer, but much much earlier. The project-wide > listing should, in principle, also remain consistent. > > ...though probably unsorted. If I remember correctly consistent sorting > is still a problem. > Yes sorting is a little off, and I'm looking into that as well. I think we need to sort on filename, line and col in that order to get it correct, right? >> - What would be the best way to get the proper line and column? Now I >> simply use the range, but considering there's a lot of error handling >> there I guess that is a little risky? I did have a version earlier >> using with-temp-buffer and finding the correct positions, but that >> seemed more complicated than needed. > > Risky for what? I don't follow > I'm thinking that if I avoid doing the same error handling as in the normal case (which requires a live buffer), chances are that the range may be wrong. But since I didn't yet see such a case, I'm thinking some of the error handling is redundant. I don't have enough proof yet to remove them, but there may be some problems that I didn't yet discover with the patch I sent. > If you used with-temp-buffer, I guess you visited the file. That would > go against the idea of list-only-diagnostics, which are supposed > to be for unvisited files (if the file were visited you'd have Eglot/Flym= ake > actually checking). So using the LSP range and converting it to > flymake-make-diagnostic's protocol seems ok. > Great! Yes, I didn't want to visit the buffer, but that seemed as a good way to go at the time, considering that it at least won't clutter the bufferlist with every file in a project on load :) >> I'd love to get your thoughts on this :) > > Hope I could help and sorry if the thoughts were a little sparse. > As I said, this is out of my cache and will be for some time. > No, this is great. It confirmes some of my hunches, so that is good at least.=20=20 > Do consider patches/changes to flymake.el as well. This new > mechanism is very new, it's possible it needs some tweaks. > I think most of what _I_ need is covered, in some form or other. I'll prepare a patchset for both eglot and maybe flymake sometime soon, and you can look at it when you have some free time and energy. Theo