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: Fri, 17 Sep 2021 00:36:17 +0100 Message-ID: <87wnngdrf2.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> <87o88v35u9.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="6669"; 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 Fri Sep 17 01:37:10 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 1mR0wI-0001WN-H3 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Sep 2021 01:37:10 +0200 Original-Received: from localhost ([::1]:45634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mR0wG-0000Of-IR for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Sep 2021 19:37:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52390) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mR0wA-0000OQ-1M for bug-gnu-emacs@gnu.org; Thu, 16 Sep 2021 19:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46310) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mR0w9-0001a4-PJ for bug-gnu-emacs@gnu.org; Thu, 16 Sep 2021 19:37:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mR0w9-0004Wr-MB for bug-gnu-emacs@gnu.org; Thu, 16 Sep 2021 19:37: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: Thu, 16 Sep 2021 23:37: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.163183538917363 (code B ref 50244); Thu, 16 Sep 2021 23:37:01 +0000 Original-Received: (at 50244) by debbugs.gnu.org; 16 Sep 2021 23:36:29 +0000 Original-Received: from localhost ([127.0.0.1]:57856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR0vc-0004Vz-O2 for submit@debbugs.gnu.org; Thu, 16 Sep 2021 19:36:29 -0400 Original-Received: from mail-wr1-f50.google.com ([209.85.221.50]:42892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR0va-0004Vh-9s for 50244@debbugs.gnu.org; Thu, 16 Sep 2021 19:36:27 -0400 Original-Received: by mail-wr1-f50.google.com with SMTP id q11so12076282wrr.9 for <50244@debbugs.gnu.org>; Thu, 16 Sep 2021 16:36:26 -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=0GIJbgjHPbgF1Ox6YRCB7zMkq91VbIZUxvzDNY1/86M=; b=PQoDG5N7YywSXUxngpHdwAU9f01WaHm5iUpmqTz0jOvnxpKpn7ZP0HIsLvPj1FXJT8 UbIFLpTVRUQ1HK4IDIg5M0w1KhH83Xt9yY5MfGlvwiLZaydWt1hBURRHAMZ6ljJKLlW6 55cfkp4PZw4sZjj2IQgDMCorm0jmwUhjOszNaBx9zNGmO+6pas4LMe1CnBhT0SZoYMC3 yTdkk8UszYDD/GoDBQdNSbmGWdOOJYFbwBRNnpMQRIYbdW/3EjDDB79pgOFXTi1PIy8E j2cGODkLmeH1vZ6G990R8/Y72rGTixde1pC+tD2Ncw70DyvFMRIvQYedn162WIV0z/v3 K8/A== 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=0GIJbgjHPbgF1Ox6YRCB7zMkq91VbIZUxvzDNY1/86M=; b=Fn6aDiv9NLh6SefC6ZZlZigTNuAtCWJg1vzD48LSKMK6CrmgoGq57hpR0tnMls9kmn 6ZgVsSXoAPelswaujFn0UZcwoVJBKKlEX6nBlKqrbi8FMbLo2vXOw+r65AzxoBfWMuF/ 4HLUttLKIgWgBvgCbkGF/B6WZNE8IBtMZgIEJWQdK2S9oHSEVH09wafujO7Mxmn/kkel KnCdcuZGaND9xWcsDmLsAdKFopI4PEEOd/cbwfbuYTpIFK0Zd0OXDiOZAgO3vTqJ8cBD cmE9cOswR5O5xMIJKIRw8qgR27tHKida5WfrcR+VmomqQgRAXkb6rFaog9LhMigAK3iB d2wA== X-Gm-Message-State: AOAM532FxK2hkMY/Iw5GvJ9SrHXHCc8pav06HX4jUJmplygISTwf1nX+ QRw+4myGN9JnB3Ki4vj/xzE= X-Google-Smtp-Source: ABdhPJw9nSW93LBjE8yuZ2I+BJFHh06I0TgkwZBXG7Ro3jipPDlwaWAYUAqkavaLIyzAmZd0hOOtXw== X-Received: by 2002:adf:ef48:: with SMTP id c8mr8615135wrp.349.1631835380297; Thu, 16 Sep 2021 16:36:20 -0700 (PDT) Original-Received: from krug (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id v191sm4381500wme.36.2021.09.16.16.36.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 16:36:19 -0700 (PDT) In-Reply-To: (Dmitry Gutov's message of "Fri, 17 Sep 2021 01:19:42 +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:214515 Archived-At: Dmitry Gutov writes: > It's a judgment call, but that seems fairly involved for a public API. Certainly no more complicated than what the Flymake API already has, what with synchronous and asynchronous invocation of callbacks with specific arguments. However if something justifies it, though, then flymake-add/remove-list-only-diagnostics can be created to hide the implemetation. > That's why I was thinking of a somewhat different shape: where a > backend reports a full list (corresponding to the default-directory > it's called from), and then Flymake can either show the list, or > discard it at some later point. When do they report it. In what moments? Under what circumstances? You address this questions, but only vaguely, at the end of your email. > Then you won't need project.el to filter the full global list, > delegating the job of compiling the list to the backend. That seems to > be the most flexible scheme: some authors will prefer Projectile or > whatever, but it some cases the backend will simply have a different > view into what a project it (which the user's config might or might > not reflect). Subtly losing diagnostics in such scenarios seems like a > bad outcome. I guess I can provide the full list of diagnostics for a user to plug in whatever filtering function she wants. But project filtering is what's at stake in this request and the project library in Emacs is project.el. I'd rather use project.el than anything else. And rather use in the framework, hidden from the backend's view, than talk to backends about projects, which they know nothing about. So it was a very simple decision there. > Maybe I could say that we could have two types of diagnostics (maybe > even just one: with file-based locations), but they would be > differentiated by the source them came from. Some would be for the > current buffer, and some would be for all buffers. This seems reasonably close to what the existing concepts of "foreign" and "list-only" diagnostics is. > IIUC LSP protocol provides some kind of feed where the client can > subscribe to the updates, and then it sends diagnostics with some > regularity, where latency probably varies by language server. If I understand you correctly, that's not at all the way the the LSP protocol handles diagnostics. Diagnostics are sent by the server when it feels like it. But normally, almost 100%, they are sent by the server very shortly after the client informs about a change in the "virtual file". There is no subscription. > But in any case such syntax checks much be triggered by edits and > saving of project files. > > It would be nice if 'M-x flymake-show-diagnostics-buffer' would > provide basically the same view into that data: it would update with > higher delays, but otherwise show the same data. Not sure if LSP can > send reports like "syntax checking in progress" -- if so, perhaps the > view could also reflect that. But I don't understand what the problem with the current solution is. Both f-s-buffer-diagnostics and f-s-project-diagnostics auto-update with "edits and saves". > I suppose some users would prefer to be able to show/hide info not > pertaining to the current buffer, but that's a matter of basic > filtering. Ah! I guess the two things could be merged into the same command, indeed. That's a good idea. Unfortunately there's the fact that when you narrow to one buffer, the file column becomes useless. Hiding a column not easily accomplished in the current tabulated-list-mode infrastructure. But that's just a technical hurdle. >> 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. > > I suppose the assumption is that the "list only" diagnostics cannot be > highlightable? Ye.... no. That's their _definition_. They are only for files which are not yet visited, so there's nothing to highlight in the moment of their creation. The _assumption_ is rather that when their files are eventually visited by Emacs and flymake-mode, we _assume_ that the regular ensuing syntax checks deriving from the visit and or from edits to those already brings in diagnostics. And that is a good assumption, if there's a traditional flymake-diagnostic-function capable of handling that file, which there normally is. This requires no change to that existing part of the backend, which was desirable. >>> 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). > > There are options. If the list-only diagnostics will only be displayed > in the show-diagnostics buffer (and not in the source code buffers), > the hook could run inside the *Flymake diagnostics* buffer the first > time it is initiated. Or flymake-global-diagnostic-functions (let's > call it that) could be called right away when a file is visited. > > And maybe it would be called again and again often: whenever the > current buffer changes, or every second after that. With the > assumption that calling it too often would not be a problem, would not > break/restart syntax checking processes (which is the case for LSP, > for instance), it would just notify each global diagnostics backend > whether default-directory has changed, and simply ask for updates > (with the possibility of optimization that the backend would return > lists which are 'eq' to each other if the list hasn't changed yet). > > Alternatively, we could go further than the approach of hooks and make > the global sources of diagnostics more like subscriptions. In that > case they would be passed callbacks which are supposed to be called > many time: every time the diagnostics change. The extra questions are > how to "unsubscribe" and "relocate" (change default-directory), and > whether to always "relocate" by "unsubscribing" + > "subscribing". Anyway, these functions can still reside in a hook, > with the general shape of each functions like > > (lambda (action &optional multi-callback)) > > Where ACTION is one of `subscribe', `unsubscribe' or `relocate'. And > DEFAULT-DIRECTORY serving as an implicit argument, though it can be > made explicit just as well. > > I'm not saying this feature is easy or anything,=20 I have no opinion. It is certainly interesting. Subscriptions, relocations... It spikes my curiosity to read this, but no more than that. It tells me that you have ideas and have put in the effort to write several paragraphs. But I cannot see clearly the problem that you are trying to solve. So I cannot see value in your idea. Nor can I really criticize it, to be honest. Maybe someone else will, of course, and it's good that you wrote it down. In contrast, I was able to see Theodor's problem clearly. Why? Because he made his own implementation that solves his problem so it's very very easy to see what he means and to address what he means. So even if we have completely discarded that implementation, it was super-useful for illustration. That is not the only way to communicate software ideas, of course, but it is certainly one of the most effective. It's one where many "thinkos" that are only natural when imagining vapourware solutions are already sorted, because reality sorted them for you. It happens a lot with me: imagining this and having to discard them once I "hit the metal". > but it would be nice to avoid having multiple sources editing the same > alist at once (that logic should be part of the framework IMHO, based > on the data the sources provide), and to let the sources themselves > decide which files are part of their "project view". They can still > use project.el underneath, if they find that convenient. Two points: * I don't see why multiple sources editing a map is a bad thing in itself. Why is it a bad thing? Just a gut feeling? Or real danger of some mishap? Earlier you said "judgement call". Not strong enough for me. =20=20 * I don't think that teaching sources about projects is a good thing. Existing sources don't know anything about that now and that doesn't stop them from contributing data to the list of flymake-show-project-diagnostics. From the start, sources are defined to be concerned with syntax checking _one_ buffer. 99% percent of Flymake backends (and probably also Flycheck backends) do this. I don't want to change them. For the 1% that happen to have easy access to some kind of information about other files, there are the new options of "foreign" and "list-only" diags, depending on how this extra info is acquired. Best regards, Jo=C3=A3o =20=20