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: Sat, 18 Sep 2021 10:59:20 +0100 Message-ID: <87r1dmcih3.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> <87wnngdrf2.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="35851"; 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 Sat Sep 18 12:00:14 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 1mRX8o-00098t-8v for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Sep 2021 12:00:14 +0200 Original-Received: from localhost ([::1]:58104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRX8n-0005Or-1s for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Sep 2021 06:00:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43916) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRX8d-0005Oi-0b for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2021 06:00:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50260) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mRX8c-0002Fr-NB for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2021 06:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mRX8c-0003xW-L4 for bug-gnu-emacs@gnu.org; Sat, 18 Sep 2021 06:00:02 -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: Sat, 18 Sep 2021 10:00: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-submit@debbugs.gnu.org id=B50244.163195917015142 (code B ref 50244); Sat, 18 Sep 2021 10:00:02 +0000 Original-Received: (at 50244) by debbugs.gnu.org; 18 Sep 2021 09:59:30 +0000 Original-Received: from localhost ([127.0.0.1]:33572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRX86-0003w8-7T for submit@debbugs.gnu.org; Sat, 18 Sep 2021 05:59:30 -0400 Original-Received: from mail-wr1-f42.google.com ([209.85.221.42]:38460) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRX84-0003vu-4c for 50244@debbugs.gnu.org; Sat, 18 Sep 2021 05:59:28 -0400 Original-Received: by mail-wr1-f42.google.com with SMTP id u18so17514273wrg.5 for <50244@debbugs.gnu.org>; Sat, 18 Sep 2021 02:59:28 -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=xw9H/tsUP+8pJEaVIZkjSxyRtejPpK/5F8+CIF5xGBw=; b=T7z9ZOLrddK+X7fXcXhatBTJW9wXqrp/o5W++RUR7cm7C+s72WMOsNrckhZlEy6IEm OsddnJA8A2BXOnMADVAyVUA9+3xJrvvPaFIVCYiTucjxqFXitPk/hR/OfU7PqroEch5G M2KHHL0m/VK2LJr8DzgfjrC4ap+Qdq8VHkYDME8ZkMSh9y6yvNdk1Ynez6Rs8QVBWF3T 62W/xEVWx54S3aqYTBOwrDOnYIl2sXXOXAk8at9r+nmOynfaQaPnqXiG220XOxZk3V2D Lt3JAPqV7wDK0E+8rwqpdYVBObKKjeC+zPbSIDOc5H1THCBZWr0PBBFbMw2tHlUmKnPy 6SEA== 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=xw9H/tsUP+8pJEaVIZkjSxyRtejPpK/5F8+CIF5xGBw=; b=p+X7c+6sNiuiFXE9cZXWZcuFp+a1TAIXHKfxDOG44ZGV+vxGBAaKpjC5RYwyVLOWG4 GRtS2mGCpXPoS3t2kODXZ8GcwuGEcsecObXvrOTpLw9ej0eX5OVcsyaGKD7Xpjhrfd5x LdFvhb+baYr/tuTMNRpxuvPemMyrx217SXTu30JzAJ7zcbm45eaVyAieyOlGCRE92VE6 bDGdNiDffFjB3E1jVctTRvCt6A3GEwKDXc0y4H9EU483yUPyoF4limzsSK+IzigqraC1 jbFBgIxWrM9hbXHDN0LqfXYZv4gM4ZSjuOzj9OrD43gzmO6BKdnaZFjkPWCPbqBiqLZU e3+g== X-Gm-Message-State: AOAM533Be+MnsaWldiNWayk0LUSeaxhFvIbmEJ1Ls9e2iB0l/L6AiuJD XqjCHTrwk8nsiqWMa5kWAJ0= X-Google-Smtp-Source: ABdhPJzMjRH/c554dvjUA4DOJOo1wpYmyanx1bn7hd7P0nkKHKnXP9ahSWYNFaemwUXv5KivIWRJvw== X-Received: by 2002:a05:6000:1081:: with SMTP id y1mr17347783wrw.14.1631959161986; Sat, 18 Sep 2021 02:59:21 -0700 (PDT) Original-Received: from krug (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id 23sm6002718wme.27.2021.09.18.02.59.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Sep 2021 02:59:21 -0700 (PDT) In-Reply-To: (Dmitry Gutov's message of "Sat, 18 Sep 2021 04:19:16 +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:214611 Archived-At: Dmitry Gutov writes: > On 17.09.2021 02:36, Jo=C3=A3o T=C3=A1vora wrote: > 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. Yes, but currently they work in one specific way. The new Flymake is compatible to that way (and all the other backends way). That's so that "people" _don't_ have to write new backends or modify the existing ones, to make at least partial use of new Flymake functionality, M-x flymake-show-project-diagnostics > But do they? Know nothing about it? I think so, yes. The Flymake backends that live in the Emacs source tree are examples, and so are many that live in Elpa. They are all concerned with the buffer. > 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. Yes, I see what you mean. Here, again, is an attempt to explain what how it works. That's up to the backend: if it knows these things, and if they are useful to its work, fine. But they aren't required and should not be required by Flymake. The flymake-cc backend uses a Makefile for example. Is that "the project"? Sometimes it is, sometimes not. Flymake, the framework, doesn't care. It cares about files in a file system. Backends tell it about problems in the current buffer and the associated files. Now they are able to tell it about other related files, within any criteria of relation they see fit. > "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 see. There's nothing in LSP that tells me that model is correct, but nothing telling me it's wrong either. > It seems more like a technical decision rather than definition. It's both. Making working definitions is technical work. I define things so that I can operate on them comfortably and succintly. I could have defined "list only diagnostics" it in terms of Aunt Mary's cake, but it would probably make for a lot more code to write, unfriendly documentation API, etc. It's just like you devising the definition of "subscription". It's a technical decision. It's one yet to see light of day, but it's a decision nonetheless. > 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? I don't know! I don't know that flymake-global-diagnostic-functions does, because you haven't written it or described it suitably. It's very hard to be your imagination's interpreter. You should type these things in Elisp and then use the Elisp interpreter/compiler. >> 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? If I understand you question correctly: the latter, but only sometimes. Servers can provide new fresh info when you visit files, so it wouldn't be the "same information". But as for the "classic hook" being used for that: yes. >> 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. Maybe that works. Maybe not. To solve what problem? I don't know. You don't seem to describe this problem, am I incapable of devining it. But if you can see and you can program it, maybe it becomes obvious then. >> 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. I think, without wanting to overly judge your stance, that that is more than slightly unproductive. (1) I solve a problem which uses "your" project.el library and its existing API (requests no changes to it). (2) You argue long-windedly that there is a much better solution to solve the problem, and presumably some other problems. (3) Finally say that you don't have direct contact and experience with the base matter, and that you don't have time to develop your ideas formally. I don't even know if you've tried the solution that I've presented and encoutered some difficulty. I have to say that it feels a bit unfair for me who has sit down and spent actual hours of my life working on something real. This pattern repeats more or less in many other parts of Emacs that I usually work on. I take Eli's frequent advice: "sit down and do the work". It's excellent advice. Then my ideas are more convincing. Others and I are more happy and less exhausted to debate them. I am going to snip the rest of the conversation, which is repeating the same points. I have nothing to add. Best regards, Jo=C3=A3o