From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Date: Sat, 18 Sep 2021 04:19:16 +0300 Message-ID: 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> <87wnngdrf2.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3144"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill 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 Sep 18 03:20:11 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 1mRP1X-0000cg-AT for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Sep 2021 03:20:11 +0200 Original-Received: from localhost ([::1]:59544 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRP1V-0006YU-Ip for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Sep 2021 21:20:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRP1O-0006YK-7f for bug-gnu-emacs@gnu.org; Fri, 17 Sep 2021 21:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49977) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mRP1O-0000Jk-08 for bug-gnu-emacs@gnu.org; Fri, 17 Sep 2021 21:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mRP1N-0002ll-Rc for bug-gnu-emacs@gnu.org; Fri, 17 Sep 2021 21:20:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Sep 2021 01:20: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.163192796710598 (code B ref 50244); Sat, 18 Sep 2021 01:20:01 +0000 Original-Received: (at 50244) by debbugs.gnu.org; 18 Sep 2021 01:19:27 +0000 Original-Received: from localhost ([127.0.0.1]:33290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRP0o-0002ks-IB for submit@debbugs.gnu.org; Fri, 17 Sep 2021 21:19:27 -0400 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:40932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRP0m-0002ke-SA for 50244@debbugs.gnu.org; Fri, 17 Sep 2021 21:19:25 -0400 Original-Received: by mail-wm1-f53.google.com with SMTP id b21-20020a1c8015000000b003049690d882so11219887wmd.5 for <50244@debbugs.gnu.org>; Fri, 17 Sep 2021 18:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=i8wqdJeY3IW7wAoWBJEx4AxyowZWdskNxvE4dkR8Fog=; b=W3nGu85GfjxFVPSABFKNtX/qMmLKyJRZRqRp/kT882QYp6vzNOWaJI2w8mnUJsLrIg XXrk6ekCo7ASmO7BzC77WoxU5j49tXVjI1iGNsMl9iCv0bH+cPDxX2YZ1m98ML4stgMX q6GhX1kibzwg0fZCelN4ZHBVcVn8MSvHvq1NUznsOdVgntL5/jxf3qbuT86l+ldmaxO/ rVmL8r9HbNKGWVtgULaiLASVpnbu+rPpoGkUdHXV9bv9PBGjgNQO40ufCebBgU0GC300 /6HIT4rO92wXYk4fdOXn1j4urZijfxOytRp8Wxks+ZmeUSak7kmrMMVj+ycQJI94fXxT 6z6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=i8wqdJeY3IW7wAoWBJEx4AxyowZWdskNxvE4dkR8Fog=; b=ZE6iBz+Ngylkungcq0oLbFKvALu+9dhfgEO4gotLaNMQ7huYM+rA/2vfmusC7Eflgm VldNqiw5FKDr2ZjLIFISOP0K7o/m5ZZuvB6X/5Jgu3SGRr0VBBe/Z6Bh7yhCZnFbQggC zGfe7aqf98rIKx0CROlc2TUzBf5pfbtkXULOlMeAmIcDAqjr/Wyn0+Q5m2/ViXoNVWxS KGALTswjrzTTaxGELpRzZTUM4CbC9wM01sLpLPI5vueEzz+7bY9IRxnicpptcCsdQN3i cM9zSZiIdiMaXfELPE87l7lrOk2+E654BcLlbaOBR38ZW3vz+AJNg2S+RtLglczMAEZG sDZg== X-Gm-Message-State: AOAM532S7tpzcVIGlH2aPVGzLDLlz7vgykecKqrI3txqrtnwTdJLV8ih BOsxZIphYpwoYJEc/ETxnqM= X-Google-Smtp-Source: ABdhPJztlMyJIHu9sNWRJL8NbG9iEG6VldnxzUJ8wEf1KsX3J5IsF4AJQDvBATdFE5fHkwUJRN0tCg== X-Received: by 2002:a1c:cc03:: with SMTP id h3mr17641112wmb.73.1631927958779; Fri, 17 Sep 2021 18:19:18 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id c9sm8679935wrf.77.2021.09.17.18.19.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Sep 2021 18:19:18 -0700 (PDT) In-Reply-To: <87wnngdrf2.fsf@gmail.com> Content-Language: en-US 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:214595 Archived-At: On 17.09.2021 02:36, João Távora wrote: >> 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. Ultimately, those answers depend on the kinds of diagnostics functions people are going to write. LSP diagnostics, IIUC, can work with any of the options I described. >> 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. But do they? Know nothing about it? Consider where "list diagnostics" can come from. If those span not just the current file and maybe a couple of files which it include<>-s (in the case of C/C++), they have to span a whole set of files, which often corresponds to the notion of the project, as understood by some tool or configuration file. So the knowledge about the project bounds seems necessary to even be able to generate the global diagnostics. >> 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. Yes: I'd rather those use the same container type. Maybe even the same reporting mechanism. >> 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. "Server sends" is an event source. It doesn't react to you calling diagnostic functions, it only vaguely reacts to user actions, which then get translated into notifications for the server, and those, asynchronously, result in diagnostic events. Events one could subscribe to. >> 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. I figured it could be more like a horizontal header. But those might be even harder to do, in tabulated-list-mode. >>> 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. It seems more like a technical decision rather than definition. To put it another way: suppose each of flymake-global-diagnostic-functions returns a list of values of diagnostics. Would those be generally suitable for highlighting files? > 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. If we're talking about LSP-based diagnostics, would those then come from some different source? Or would that just be the same information, repackaged through the classic hook? > 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. I'm thinking that if LSP servers only provide "global" diagnostics, they could simply provide all their diagnostics through the new abnormal hook. Then changing the "existing part of the backend" might likewise be unnecessary. > 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". That is entirely possible. I just wanted to touch on this discussion because it relates to a package I maintain. I'm not currently an LSP user, and other things require my attention. >> 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. It loses the "here is the whole global list of diagnostics related to the current file" type of information. I don't like losing information in general, but also I can easily imagine (possibly infrequent) cases where the underlying tool's understanding of the project will differ from the user's configuration of project.el (or the default behavior, when there was no configuration). So imagine: the tool (diagnostics backend) reports a bunch of errors, the user pops up the project diagnostics buffer, fixes the errors one by one... and then the project still fails to build because some of the related errors were filtered out when you used project.el to choose which errors to show. > * 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. So we keep the old per-buffer hook for the one-buffer checkers and use the new abnormal hook for the newly discovered exceptions. No? Maybe flymake-global-diagnostic-functions could even be shoehorned for the C/C++ case of not-entirely-global checkers: those checks would be triggered by an element in flymake-diagnostic-functions, report the "local" diagnostics to the local reporter, and then the full list through its flymake-global-diagnostic-functions element. The question is, which code would add the flymake-global-diagnostic-functions element.