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#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Date: Tue, 14 Sep 2021 09:43:26 +0100 Message-ID: <87o88v35u9.fsf@gmail.com> References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <7c6bb19d-24fa-0875-a25e-8b0739901e0f@yandex.ru> <874kao42pr.fsf@gmail.com> 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="7257"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 14 10:46:43 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 1mQ45S-0001bi-4Z for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Sep 2021 10:46:42 +0200 Original-Received: from localhost ([::1]:59762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQ45R-0002QT-6l for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Sep 2021 04:46:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57300) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQ42r-0008Vv-TK for bug-gnu-emacs@gnu.org; Tue, 14 Sep 2021 04:44:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35925) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQ42r-00008z-Kr for bug-gnu-emacs@gnu.org; Tue, 14 Sep 2021 04:44:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mQ42r-0003qm-Iu for bug-gnu-emacs@gnu.org; Tue, 14 Sep 2021 04:44: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: Tue, 14 Sep 2021 08:44:01 +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-submit@debbugs.gnu.org id=B50244.163160901614760 (code B ref 50244); Tue, 14 Sep 2021 08:44:01 +0000 Original-Received: (at 50244) by debbugs.gnu.org; 14 Sep 2021 08:43:36 +0000 Original-Received: from localhost ([127.0.0.1]:47471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ42S-0003q0-D3 for submit@debbugs.gnu.org; Tue, 14 Sep 2021 04:43:36 -0400 Original-Received: from mail-wr1-f48.google.com ([209.85.221.48]:46635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ42Q-0003pk-Ip for 50244@debbugs.gnu.org; Tue, 14 Sep 2021 04:43:35 -0400 Original-Received: by mail-wr1-f48.google.com with SMTP id x6so18854631wrv.13 for <50244@debbugs.gnu.org>; Tue, 14 Sep 2021 01:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=DXLaoxGONcXnDf3uU4QVFk2dAeWz0j8ZQVssEhNvsiU=; b=ARiixLF4Zk7Sj//vEQQal+/3BDaMDPcEYKn9Nj0lpi5dFfK9BK2fky5b1QqFHCsZhB Ln1i7Ff0bZNUQxD5s0eGumCW76K97bDgj2URe4/dtIgwDZxjTJiokXDyXRIi8x3PjRu/ 5RmSVbsu+KJDLpt7RkL3JtKoOFGkYkrD0sQw67vB4KPB5UIEX7xBsTriu7tmYGJBO2zY yXQmAPnY0y0eA/tjT1fYlvUfdyBIoqMoXQqjDrsvQH56QvYtioHSSPCcHxy27VmPWDC3 XX2w4Lhen0pwaHrCTX9SbH8aeUG3NlxlJ+3eG5KdhYVcBKgqqSg9S9yyilHI+bBf9VWY P7eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=DXLaoxGONcXnDf3uU4QVFk2dAeWz0j8ZQVssEhNvsiU=; b=NNxK+7k0iQZlPVD7OVBRaxsJsZK4/jXggkg6j6/0NazQYkOOWpTt2I3XT6AaCgtJjB 4Kdt0vwZGFAOg5NMGGsxLYdDWDTORT3RthYDxhp0NxguRAf8sbXyhgCG8gwqkX/UZ1NO W67yWbxHSyFHJ9afy/bgED1etmQn+aC913VLSsORgDuFOXAeQ2Lx+2WsI1ZWmMdvGv/x 7hDfu2fLrJK9MCcHgcNl3k3KDow9skPuOIKfbpBief4RghLSGv33T97g6sTdrJXtzTg8 kU9/KGDCnY4PADzwrJunJu7l43Ow8aWCW83TTC0mQ4Kkqk6FX/8EabcOuKnp6qaHJjpD Fxvg== X-Gm-Message-State: AOAM531owQ+TCPaMekbkKrFf/WxGtln5NJjPfqrioJeeBP1MG3iyVeVm 2Ig/fq/mcL4myAg3yIXutws= X-Google-Smtp-Source: ABdhPJwBYJ3B33gMT0qj8PTgPK9G1o/TMrSJXJo4Eb57Xl9jFlwfIOK9K0mV19CdLzcD7mx+g7wpnA== X-Received: by 2002:adf:9e4d:: with SMTP id v13mr17451356wre.419.1631609007501; Tue, 14 Sep 2021 01:43:27 -0700 (PDT) Original-Received: from nadja (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id z6sm500073wmp.1.2021.09.14.01.43.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 01:43:26 -0700 (PDT) In-Reply-To: (Dmitry Gutov's message of "Tue, 14 Sep 2021 02:35:51 +0300") 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:214284 Archived-At: Dmitry Gutov writes: > On 13.09.2021 23:53, Jo=C3=A3o T=C3=A1vora wrote: > >>> Anyway, I asked about this because because the use of global variable >>> (flymake-list-only-diagnostics) seems like it would make supporting >>> multiple projects at the same time more difficult. >> I can't guess what you are hinting at, sorry. You can call M-x >> flymake-show-project-diagnostics in two or more projects, of course, and >> you'll get separate listings. I don't know if that counts as >> "supporting multiple projects at the same time". > > If a backend reports diagnostics through > flymake-list-only-diagnostics, woudln't one of those values be > overridden when two backends offer reports? No. The variable is an alist (could be another type of map), so backends only add and remove entries about the files they know about. The "and remove" bit is still under study. For now I've chosen to leave the "remove" responsibility to backends, but I've experimented with schemes in which flymake.el does the removal strategically. I'll re-study that. Also, perhaps you're being confused by the variable's docstring, which is not as good as its entry in the manual. I'll try to clarify later. >> Again, I don't understand your suggestion, but if you can propose it in >> the form of code it would be much better, since there would be no >> ambiguity. A word of caution though: making these things work correctly >> in tandem with domestic diagnostics, new file visits and buffer killings >> was relatively hard. I tried many different approaches and settled on >> these two ("foreign" and "list-only"). Of course if you can clearly >> describe a use case where they are unsuitable, a third style may be >> invented. But I would first exhaust the possibilities in these two. > > I was thinking of a way to get by with only two types: "domestic" and > "foreign", without adding a third one. Those two already exist. "foreign" diagnostics belong to a given source buffer's flymake-mode but don't target the source, rather other buffers or unvisited files. Like "domestic" ones they are systematically updated as the source is updated. They are well suited for flymake-cc and strongly typed languages where a compilation unit is created from the strongly coupled aggregation of many files and checked as a whole. As you know if you've ever done C/C++ the locus of a syntactic mistake is usually spread out through one .cpp file and multiple .h files. LSP servers don't systematically provide this info -- as far as I have witnessed, so Eglot can't do much with them. If I'm wrong, then Eglot will also use this functionality. The LSP protocol doesn't forbid it. Maybe I'll approach clangd developers with the idea. Currently, what _can_ be seen in the logs is an LSP server shooting out a once-only batch of diagnostics for the whole project of unvisited files when the server is started. That is better suited to "list-only" diagnostics. Why "list only"? Because once the actual file is visited, it is assumed that flymake-mode will kick in there proper and be able to request fresh, domestic, highlightable, diagnostics to override the initial "list only" that came in the starting batch. > No code, sorry. If you want a new abnormal hook (as you seemed to propose), you have to say, at least in some kind of pseudo-code, _when_ that hook is going to be activated. Maybe by doing that I could start to see the problem that it is solving (I also don't see that). Jo=C3=A3o