From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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: Sun, 29 Aug 2021 00:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 50244@debbugs.gnu.org, theo@thornhill.no, p.stephani2@gmail.com X-Debbugs-Original-To: bug-gnu-emacs@gnu.org, Theodor Thornhill , p.stephani2@gmail.com Received: via spool by submit@debbugs.gnu.org id=B.163019839824658 (code B ref -1); Sun, 29 Aug 2021 00:54:02 +0000 Received: (at submit) by debbugs.gnu.org; 29 Aug 2021 00:53:18 +0000 Received: from localhost ([127.0.0.1]:55183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mK94Y-0006Pe-B5 for submit@debbugs.gnu.org; Sat, 28 Aug 2021 20:53:18 -0400 Received: from lists.gnu.org ([209.51.188.17]:56650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mK94W-0006PS-DS for submit@debbugs.gnu.org; Sat, 28 Aug 2021 20:53:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39372) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mK94V-0003uE-Ts for bug-gnu-emacs@gnu.org; Sat, 28 Aug 2021 20:53:15 -0400 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:38597) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mK94U-0006mm-6e for bug-gnu-emacs@gnu.org; Sat, 28 Aug 2021 20:53:15 -0400 Received: by mail-wr1-x42a.google.com with SMTP id u16so16638058wrn.5 for ; Sat, 28 Aug 2021 17:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=GSA/SjyYHCyH0SwZr94dAyPnUKaLZqkKta4uvWKYfBc=; b=g7gui8q8PYIqe7GyW2uOy6P9csxpUVV2uRjYVfJFS0X3ODl4bEXSlNEitiE6Z8ve7a c3jV7vhdmDePBPl7L5rshm0X0g/zBVtrB2Q4tL6Qr5vTYFuwWv9mLia8USvDRkz7+Wug M9LBtYsh1gyv6NdYdscDcmZUIczIwJ4MDhQmKB+u+shGHooSuh9znm4vPfl7R7nBxZoK Bqv78v8k3MB7NIdO+Nn0Fn0i0O3+59wvLkoLpMJBZInMoG7P8K06ecs85pC7JrT/HkUe YccD65Llllb904FZ51cu8XCk+QsAgssOWHDo+K+1mDC2jN8RwoHnNxQECa+38NroQjzR Jnfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=GSA/SjyYHCyH0SwZr94dAyPnUKaLZqkKta4uvWKYfBc=; b=tgetEj3Vo1MqPsCT8VYEfSsVufA8eyMjN1bSzBu+ZW8CPZ3NoV/QbEEFUd+sHLwPwB Fd+qB/DxmsFFFpTXMTWCec5vVh4Lgbj6EH9AEiQUl8P9BchBpLp4VxDWTJFreEsITHdk VzgA3c24bhoHFHR6Ew7AQn7MZNrkDPBh2S+LIJCRpzQw4aE2EjJUWbyiNxgpChjgZo5p tus2yM7b7BstHT1C36K/FTZKutS9/C8QdkZuMlTDlHoSVpTClRMxfyfpS/B15pKZbdJx 2vCYH6cgYdKKmCvoeOJZhN1JvMv0Hlc9QvwFXwmp1+L+Ecj9Ud4awncyDhW2yEnH7j/i JSCA== X-Gm-Message-State: AOAM533nUZENMpuh3RXJYRvvjKmmPAyEF/FN9L7dIkSqnsZd3vTd/3HA axPJ4pK1e4qrU91p9PVOLqU= X-Google-Smtp-Source: ABdhPJyepuMdhVMYhF0IQaX+yho5GvX38w1A51mvc7tH0rUNVmsdzxuIXja5kgULm+OyjEAdRRLAXg== X-Received: by 2002:adf:9f05:: with SMTP id l5mr17858423wrf.188.1630198391548; Sat, 28 Aug 2021 17:53:11 -0700 (PDT) Received: from krug (a94-133-103-226.cpe.netcabo.pt. [94.133.103.226]) by smtp.gmail.com with ESMTPSA id y6sm12910910wrm.54.2021.08.28.17.53.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Aug 2021 17:53:11 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Sun, 29 Aug 2021 01:53:08 +0100 Message-ID: <87bl5hm5qj.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is coming from: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D34418 https://github.com/joaotavora/eglot/pull/640 In the first, Philip wonders why the BUFFER argument to flymake-make-diagnostic is mostly ignored. In the second, Theodor requests that the Eglot LSP client manage and display the diagnostics reported by the LSP server not only for the current buffer being edited, but for other buffers or files. The connection between the two will hopefully become apparent soon. Normally, diagnostics reports are emitted by diagnostic backend for a single file, usually as a result of a change performed shortly before in the buffer visiting that file. This is true for most LSP servers when acting as Flymake backends. But some LSP servers seem to take this opportunity to also "piggy-back" diagnostics for other files, in a kind of "side-band signal". Other servers yet will sometimes report diagnostics upfront for all files in a given project, whether visited by a buffer or not. Theodor's pull request handles this side band signal for LSP specifically in the Eglot client, but it contains some twists and turns that should not be taken in Eglot. This functionality should be supported in Flymake. * What kind of new API support for Flymake backends is needed for this? This is the good news: I think not much. The helper function flymake-make-diagnostic, used by Flymake backends such as Eglot's, already supports a BUFFER first argument, but, as the manual states. =20=20=20 Currently, it is unspecified behavior to make diagnostics for buffers other than the buffer that the Flymake backend is responsible for. =20=20=20 My idea is to make it specified. As floated in bug#34418 I think the idea of generalizing the argument to mean BUFFER-OR-FILE is decent and sufficient. * What kind of infrastructure changes in Flymake are needed for this? That's more complicated: substantial, but not insane. Here's a top-level plan: the current buffer-local variable flymake--backend-state should probably first become a global hash table indexed by buffer, which should be mostly indistinguishable from a buffer-local var. If that works, then it should be possible to store the piggy-backed diagnostics in (1) file-indexed entries to that global hash table, for files which are not being visited by buffers. It should also be possible to add (2) buffer-indexed entries to it for buffers which, though live, don't have Flymake properly activated or don't have that specific piggy-backing backend in their running backend list. These new types of entries will likely not contain the full-blown flymake--backend-state structs, i.e. they will be missing the 'running', 'reported-p' and 'disabled' slots. All they will have is a non-nil list 'diags'. If, for situations (1) or (2), we discover that a "proper" buffer-indexed entry already exists in the global hash table, we must decide if the information in them should take priority. I'm not sure of the answer to this yet. Anyway, in flymake--handle-report is where the recording of information should happen. We can have a look at the current aforementioned "unspecified" behavior: (setq new-diags (cl-remove-if-not (lambda (diag) (eq (flymake--diag-buffer diag) (current-buff= er))) report-action)) (As we can see, the current "unspecification" is just ignoring reports for BUFFERs other than the current.) * In what new UI parts is the augmented information to be useful? Currently, I see only one place, the diagnostic listing buffer obtained by M-x flymake-show-diagnostics-buffer. That buffer is usually associated with only one source buffer (flymake--diagnostics-buffer-source). Now it should start listing all the diagnostics for buffers or files known to belong to the same project, using 'project.el' functionality for that. Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Aug 2021 23:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 50244@debbugs.gnu.org, theo@thornhill.no, p.stephani2@gmail.com Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163027968111356 (code B ref 50244); Sun, 29 Aug 2021 23:28:02 +0000 Received: (at 50244) by debbugs.gnu.org; 29 Aug 2021 23:28:01 +0000 Received: from localhost ([127.0.0.1]:57738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mKUDZ-0002x6-Da for submit@debbugs.gnu.org; Sun, 29 Aug 2021 19:28:01 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:52045) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mKUDY-0002wq-CM for 50244@debbugs.gnu.org; Sun, 29 Aug 2021 19:28:00 -0400 Received: by mail-wm1-f51.google.com with SMTP id u15so7651810wmj.1 for <50244@debbugs.gnu.org>; Sun, 29 Aug 2021 16:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rAmbFyk5T+IIgPkQW2TdYk1o+379sHiKmwL7dbbh6IM=; b=EHUbK8Ben8h1RUyPEA9sSGw+kawFoXxrriQMTjbnC1F34f2ayDEXVAiy9IU8oQyyz+ YgnOu7tfdG9+ewnWV43UjE45mVQAxFNQwLAXEN2SZ0L/Vz4MeHrG7MZgeQHdEG6q6s/d 7dnBD0ryPoP/rhQTVzkEymACor+Zb55Ie1lRb09VtXuEBdWD6bNZiDfxGVU74rh7fEeb DNGdfCvhn7PaX5fG4UvYeRskTa8P8D1S8tl4g0Aow1dA1Gq+yImOAJn6F9GZLfWHPs88 T62MZIMNd3A9a9bmZY6VbC0gOGH+oHTzTO2K5t4xHMSu8YASPhwpfbM1UClkBC71Imfv Yt4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rAmbFyk5T+IIgPkQW2TdYk1o+379sHiKmwL7dbbh6IM=; b=Kpcy4Zr/MtcqjVsmE7jq+e9PNdZ+Bf5ficUkH6I/Vw4FGYGeVNuaOP9HT2PoieZEhD u+Blahf5H9Q4bIjkNHHlHaRXNtxdEzW4llNrjtO1QMrs//KkWXl/AuTy/r5I+zSLVBhR 6ASa3BuqwZUXTPmRn95OMpN0JoOBFt+7i2MA4z0L5qpLxEGBNxEcDRVgiicSBgNdYQgc 5S4fR+GyBvMD7251wiR7PYl3HtdlA+Te8vyyM9pOmxQyYIw3WBqbWBQx8i1apiK5TC3b Ful2uXCBlgceEqeM/SLhm/4E65cNT6VfYyYRQm9sE24R71Luy0Mdoo+w51L8g51m1Wel taJw== X-Gm-Message-State: AOAM530CvxOyXU1CpG9xGvzyN76JhOwIdPJ03Ymb3mmNpyUk/UDnsYFc O4RruHGWffnf1XrRxEr2nSQ= X-Google-Smtp-Source: ABdhPJzY+pr+VpcCIFZV41Z1rE7qLAUmBVzRlOd4OgMKTuhx41M72bxb71iVEsdfG0NrzmAaSWZVOw== X-Received: by 2002:a05:600c:3591:: with SMTP id p17mr30737092wmq.134.1630279674464; Sun, 29 Aug 2021 16:27:54 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u16sm13405441wmc.41.2021.08.29.16.27.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Aug 2021 16:27:54 -0700 (PDT) References: <87bl5hm5qj.fsf@gmail.com> From: Dmitry Gutov Message-ID: <8dfca367-baa8-c4ae-8e6b-8ca41d5a63d6@yandex.ru> Date: Mon, 30 Aug 2021 02:27:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87bl5hm5qj.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 29.08.2021 03:53, João Távora wrote: > * In what new UI parts is the augmented information to be useful? > > Currently, I see only one place, the diagnostic listing buffer > obtained by M-x flymake-show-diagnostics-buffer. That buffer is > usually associated with only one source buffer > (flymake--diagnostics-buffer-source). Now it should start listing all > the diagnostics for buffers or files known to belong to the same > project, using 'project.el' functionality for that. From what I know of this feature is usually organized, we have two possible kinds of sources of errors: 1. Per buffer, which is currently being edited. 2. For the whole project, where the notion of project is defined by the tool which produces the said list of errors. With that approach, when you fix an error which triggered some cascading errors in other files, you can see those other errors fixed too. Is the idea to build a list of "project errors" using sources of type 1? That would seem inefficient, though I suppose some people might want this too. But I thought the original discussion was about errors from sources of type 2? Then the whole list provided by the source already belongs to the same project (how the LSP server understands it, if we use the LSP example). Is there a need for further filtering? From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Aug 2021 07:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 50244@debbugs.gnu.org, p.stephani2@gmail.com Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163030684730242 (code B ref 50244); Mon, 30 Aug 2021 07:01:02 +0000 Received: (at 50244) by debbugs.gnu.org; 30 Aug 2021 07:00:47 +0000 Received: from localhost ([127.0.0.1]:57968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mKbHf-0007re-0y for submit@debbugs.gnu.org; Mon, 30 Aug 2021 03:00:47 -0400 Received: from out2.migadu.com ([188.165.223.204]:64531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mKbHZ-0007rL-Fh for 50244@debbugs.gnu.org; Mon, 30 Aug 2021 03:00:42 -0400 Date: Mon, 30 Aug 2021 09:00:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1630306835; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mZowqPTFbKtX7niLurzXBlMVdCDAN9Ir54se571vL8Q=; b=NVlR4OUlOEK/0RYJQ2zI/3mHo7N+Dxp262FVwzXzDpPiIAoT3F9HGP8Ydns7XVxm8OdQx0 RbwUJ4xdgrOibC4ow/GgcSzyi6hkvEe+10sFCuJ9dvmi531PsX0IUzwlxslDXvq7akxad4 2fAKWAE/DpcBpsK0B6kwVhNn+BZK6AdlcN/4UXDULVCZgPavqoLpg+vzN7t2EOsI7JZd28 bTokeiqeg50+1yzZLMhqMOI0Q7dpuMmDug9TGlywEx5uzyhi5NT/JlxE2zdLw8bXJvEJ7x zzJU3KD7ma0CgzXWXX03lxcNaGToYuebvUS1FElt7qGNaG3b4WEJE4yWfkazow== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill In-Reply-To: <8dfca367-baa8-c4ae-8e6b-8ca41d5a63d6@yandex.ru> References: <87bl5hm5qj.fsf@gmail.com> <8dfca367-baa8-c4ae-8e6b-8ca41d5a63d6@yandex.ru> Message-ID: <174BCB34-6273-40F4-8F58-12BAC76E6702@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 30 August 2021 01:27:52 CEST, Dmitry Gutov wrote: >On 29=2E08=2E2021 03:53, Jo=C3=A3o T=C3=A1vora wrote: >> * In what new UI parts is the augmented information to be useful? >>=20 >> Currently, I see only one place, the diagnostic listing buffer >> obtained by M-x flymake-show-diagnostics-buffer=2E That buffer is >> usually associated with only one source buffer >> (flymake--diagnostics-buffer-source)=2E Now it should start listing= all >> the diagnostics for buffers or files known to belong to the same >> project, using 'project=2Eel' functionality for that=2E > > From what I know of this feature is usually organized, we have two=20 >possible kinds of sources of errors: > >1=2E Per buffer, which is currently being edited=2E > Yes, and some LSP servers may only deliver this=2E Typically, though, serv= ers send to gravitate towards 2 these days >2=2E For the whole project, where the notion of project is defined by the= =20 >tool which produces the said list of errors=2E With that approach, when= =20 >you fix an error which triggered some cascading errors in other files,=20 >you can see those other errors fixed too=2E > >Is the idea to build a list of "project errors" using sources of type 1?= =20 >That would seem inefficient, though I suppose some people might want=20 >this too=2E > In the case of elm-language-server, with which I use the most along OmniSh= arp and F#, all of them report all diags in all files known to the project = (as defined by LSP) on the first load, then all potential diags across all = files per edit afterwards=2E This case get super chatty very fast, but sinc= e it always flushes everything one can at least rely on what you get=2E The= pr I made works pretty well performance wise in a medium large repo (~70k = loc elm), at least considering it isn't very polished, awaiting this discus= sion=2E >But I thought the original discussion was about errors from sources of=20 >type 2? Then the whole list provided by the source already belongs to=20 >the same project (how the LSP server understands it, if we use the LSP=20 >example)=2E > >Is there a need for further filtering? Not in the case of LSP, no=2E=20 In addition, the structure the error buffer uses would be nice to expose s= o that one can build utility functions like the ones in the pr=2E Theo From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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: Mon, 30 Aug 2021 08:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 50244@debbugs.gnu.org, p.stephani2@gmail.com, theo@thornhill.no Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.16303131987776 (code B ref 50244); Mon, 30 Aug 2021 08:47:01 +0000 Received: (at 50244) by debbugs.gnu.org; 30 Aug 2021 08:46:38 +0000 Received: from localhost ([127.0.0.1]:58085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mKcwA-00021M-Ij for submit@debbugs.gnu.org; Mon, 30 Aug 2021 04:46:38 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:40872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mKcw8-000216-Qh for 50244@debbugs.gnu.org; Mon, 30 Aug 2021 04:46:37 -0400 Received: by mail-wr1-f43.google.com with SMTP id t15so15072144wrg.7 for <50244@debbugs.gnu.org>; Mon, 30 Aug 2021 01:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=UrBOZ1u37dzIeN72QEyr18cJ3dehnn5XE8+1UTIGpkU=; b=MYtf8jxoAJGIaEkru0S5gA+s4wp/dUGZWorTy/wGu1COnkePGskRnymbI0N4iuaP73 gFNLf+W57J9IXng8qzMMZtJ0eMG6NdhJkz0U88Cj5V3hVDqQGENkE9/BhmwZiyi0p1bD bGOSMAI+3js/kLCrhuAvtyOZxMprUuqQ3X0OMmFOpeVdad3eS9ETsiJhBX0CGTBlcqIq WaqQ9l9mTgQXQ3vic7Tq15HvShazWaVSME8W8gvHNVdFXxoGnmZ41NJXPcxxvTZP6KTL gbi8kOX2bsutHtdaNuSgnya0bjJMq2Vet6cp5vV9pj9f3Q9fto0jsGK4YUu479RxEOAR 1mXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=UrBOZ1u37dzIeN72QEyr18cJ3dehnn5XE8+1UTIGpkU=; b=rcF1MtcTuZ31l1NAGmIIbt1ryHpFzO3yewYdyp3GKM7MXHUt6tSvVKwiT+MVk9tIRI ibyFEyldTxgSRAGue0FhmNLg3gtJrdaAxgH6wrpW/pMyFhPaCuyz5rFYx/JUTb7E+soC TGFjXDZMcOkxgV9jaU1Mzm8ZbEahfNwoS2bru3Nyo/HKEqx8OJih2JRqlQJRJaB1OT+F jO12QoF9iC4chZz5NNV6CWq9DX3oI+QygRdpgUX2Li76mea7UvL4C9H0u2tGQP8FEdM5 b5dwOxhKnEPijUmNHLXfD6V/+Dqu1i6mwVs0wx41TEMwUKRV8VuLTgh8QEIEdg7LBxBw OgRA== X-Gm-Message-State: AOAM5317b0G8v5axZL/7tiRQ3CwVB05m1FWk5VdTnoitj4ttNkQm3Jql zbNOmDAA3LKEvKejjN104hc= X-Google-Smtp-Source: ABdhPJzKvarglOBrMKM5k61IPke5IDV+I1FVOQD+4A5QZhh65jKT4ej8KCsefgaGpO//JAAXFAy1vw== X-Received: by 2002:a05:6000:1623:: with SMTP id v3mr3298099wrb.288.1630313190754; Mon, 30 Aug 2021 01:46:30 -0700 (PDT) Received: from krug (a94-133-55-158.cpe.netcabo.pt. [94.133.55.158]) by smtp.gmail.com with ESMTPSA id z137sm20199200wmc.14.2021.08.30.01.46.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Aug 2021 01:46:30 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87bl5hm5qj.fsf@gmail.com> <8dfca367-baa8-c4ae-8e6b-8ca41d5a63d6@yandex.ru> Date: Mon, 30 Aug 2021 09:46:26 +0100 In-Reply-To: <8dfca367-baa8-c4ae-8e6b-8ca41d5a63d6@yandex.ru> (Dmitry Gutov's message of "Mon, 30 Aug 2021 02:27:52 +0300") Message-ID: <87a6kzl3q5.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 29.08.2021 03:53, Jo=C3=A3o T=C3=A1vora wrote: > Is the idea to build a list of "project errors" using sources of type > 1? No. The current idea is, in short, to not have Flymake discard information of what you call "type 2" (and which I described in my email). As I wrote there, examples of discarded information can be project-wide diagnostics sent by LSP servers on server startup, among others. For a non-LSP example, consider references to errors .c in files when editing .h files. In other words, this is a "best effort service" by flymake.el: the topic of this bug#50244 is _not_ to augment flymake.el to somehow change the way that diagnostics are requested so that somehow more of what you call "type 2" can be gathered. To be clear, after this feature is done, diagnosics are _still_ requested per-buffer. Eminently, on buffer changes and less frequently on occasions like visiting a file. The idea is simply to not discard what I called "piggy-backed" or "sideband" information about diagnostics in other places, which will frequently originate from the aforementioned per-buffer requests. > But I thought the original discussion was about errors from sources of > type 2? Then the whole list provided by the source already belongs to > the same project (how the LSP server understands it, if we use the LSP > example). Is there a need for further filtering? Yes, and even in the .c/.h non-LSP example that is true. But depending on what data-structures are employed (I'm still thinking about them), utilizing project.el's basic features for composing M-x flymake-diagnostics-buffer _may_ come in handy. This is pretty secondary at this point, in my view at least. I first want to have the information recorded and correctly updated in Elisp memory. Then I will think about how to present it to the user. Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el References: <87bl5hm5qj.fsf@gmail.com> In-Reply-To: <87bl5hm5qj.fsf@gmail.com> 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, 11 Sep 2021 01:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 50244@debbugs.gnu.org, p.stephani2@gmail.com, theo@thornhill.no Cc: Dmitry Gutov Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163132253323671 (code B ref 50244); Sat, 11 Sep 2021 01:09:01 +0000 Received: (at 50244) by debbugs.gnu.org; 11 Sep 2021 01:08:53 +0000 Received: from localhost ([127.0.0.1]:39337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mOrVk-00069j-Mp for submit@debbugs.gnu.org; Fri, 10 Sep 2021 21:08:52 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:46825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mOrVi-00069T-SN for 50244@debbugs.gnu.org; Fri, 10 Sep 2021 21:08:51 -0400 Received: by mail-wm1-f43.google.com with SMTP id m25-20020a7bcb99000000b002e751bcb5dbso2491484wmi.5 for <50244@debbugs.gnu.org>; Fri, 10 Sep 2021 18:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Necd2Hbt8bV74WxBzQIeBKbgrImsycerXT4zgcXsC7k=; b=izOW+09BJmbEHvsXZ0Gj0WWvgwoNF6feDiDyxSZ7+aVmEFtvFfkkl1e9Rp+EDd/KaU vLYIdnI5E0SExOjXB48ES4Ek9k1U1MQwKIYS1B0ls8qKogWBttSMCNFcjE/Go2UPQmp2 kBJI4DQWLS1IGlvZW3h1UUzQhmt1bnGin+S/H2kSmKwVuhIqPOZ6eA6bMr/aqopJgxzI XFxNE9b3iKVqj8k2DX5BmT6NDWczzjb/YL9cFGIhO/ZFMZOJljhIY/zvLidT0gPgMmU1 EO5OsTdRa/6J5hWtCqZo9OAop0PVxsbV6Hv3Pu9zziGlXGTxO/WblGDcVsg3ASRjFYOW NH4A== 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:date:message-id:mime-version :content-transfer-encoding; bh=Necd2Hbt8bV74WxBzQIeBKbgrImsycerXT4zgcXsC7k=; b=lvWcBtIWCKp8SxGh8njVyOinoCSnFTUBJfQu/AE5WGKNkwaQy2UCwF1C9ktl+f2+4u 4pVwv3qXYW0v7TRAhKeGKTncvgcYrt6f8uuoT0aDux0wy55I6bVwFbPkKnHc5qHyg7XH szRA56BqkTcSY6riXTlxtN+4GvExZp74/XnAPOWfmXkm6yO98MQPh02wtkj7CvawmvAQ NzuaKvSGRvfb/kuNDoXZcIETfQn4OBv+rpyymHAoUvGzgJpEo2HSbQSwwRIh5P5MIc6H nMaoMb4ln55FMT4W1P+FVcFv3adAMGzEjuPLVAU7M+RXKi7hhdVpSerYR2B2EP3afsMe 8r7A== X-Gm-Message-State: AOAM532i9ScD/P7U81H/MWTErCGXs9QFVs7Yz/WvGZM761bp7vNDnosO Vj2i4ck8+em4BMM4f/QyO8w= X-Google-Smtp-Source: ABdhPJzE3lxaB6Br/2BPuvebrxO6o85K6je/bhD9EQ2bblrqHhRSu509Pyl2qGMmmr0tDUIiQpRrUQ== X-Received: by 2002:a05:600c:2101:: with SMTP id u1mr408272wml.45.1631322525021; Fri, 10 Sep 2021 18:08:45 -0700 (PDT) Received: from nadja (a94-133-14-55.cpe.netcabo.pt. [94.133.14.55]) by smtp.gmail.com with ESMTPSA id n4sm204681wra.37.2021.09.10.18.08.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Sep 2021 18:08:44 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Sat, 11 Sep 2021 02:08:42 +0100 Message-ID: <87y283536t.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > The idea is simply to not discard what I called "piggy-backed" or > "sideband" information about diagnostics in other places, which will > frequently originate from the aforementioned per-buffer requests. Hi, I've been working on this quite intensively and am finally approaching sometehing stable. You may check my ongoing work in the branch scratch/bug-50244. As expected, I abandoned/reformulated much of my original design ideas many times as I faced new edge cases. It was quite challenging to support the main new command, M-x flymake-show-project-diagnostics, when e.g. .c files referencing problems in .h files are killed and vice-versa in various orders. If you're interested in understanding how it works, the main entry point are the additions to the existing documentation, the manual that lives in flymake.texi and the docstrings. As is explained in the manual, there are two types of Flymake diagnostics: (1) the usual diagnostics for the current buffer, and (2) so-called non-domestic diagnostics, which might be "foreign" diagnostics or "list-only" diagnostics. The difference is explained in the new manual section "Foreign and list-only diagnostics". How does this matter in practice? - For the examples of .c/.h files (and the flymake-cc backend, which I also updated), "foreign diagnostics" are used. - For LSP, likely "list-only diagnostics" should be used. So basically Eglot will soon learn to tell Flymake about the "list-only diagnostics" that it receives from some LSP servers. Once that is done, M-x flymake-show-project-diagnostics should ideally do most things that Theodor wants. Even though the protocol is already designed, flymake.el is still missing the implementation of "list-only diagnostics". It should, in principle, be much simpler than the "foreign diagnostics", which as I hinted above are much harder to keep up to date. I hope you can have a look, Thank you, Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Sep 2021 00:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 50244@debbugs.gnu.org, p.stephani2@gmail.com, theo@thornhill.no Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.16314917025796 (code B ref 50244); Mon, 13 Sep 2021 00:09:01 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 00:08:22 +0000 Received: from localhost ([127.0.0.1]:43682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPZWI-0001VQ-Kj for submit@debbugs.gnu.org; Sun, 12 Sep 2021 20:08:22 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:40871) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPZWH-0001VA-Fd for 50244@debbugs.gnu.org; Sun, 12 Sep 2021 20:08:21 -0400 Received: by mail-wm1-f49.google.com with SMTP id b21-20020a1c8015000000b003049690d882so2822572wmd.5 for <50244@debbugs.gnu.org>; Sun, 12 Sep 2021 17:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IKVpSZU8grIdCxnPXhSS/IXuCLWv715hd5O3t6Zke3k=; b=GjRjYtji5RBDkOFSgaZenEbPZLsDgV/n6Wzw5rgccGcp/+NGPWkDJqm73wD+t/dbCz SlPUVKLuJGjt6k9BgC8jraTYDaBVvvYhOArNv21xS9CcIag8dE6Vx0JQNgdub3arD8+v jsMHj9vIQsofMOSxfZtnsXooXc8BKctXCaty+b5HAk8EDG4Kf1rjTMpx1njXYytN5Mfg t84eDOMWRQPe6mNgVry2w+uhyS+KvLvBN762Biqs45muTCYToE/T5NTtYj0hox0k9Yv4 o1eFSniUbHfzKLLJ3FzxzVKmSH8r5fS4thO+d25PKSDjAAvNBTv1gdtozsUheBohUV91 fF5Q== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IKVpSZU8grIdCxnPXhSS/IXuCLWv715hd5O3t6Zke3k=; b=R6zKT7Zu0ZgPXyL9d2FHTN4avjQs+G7T8fso5Bn9op6D9iLrwtNZpPFWnU0U2hT/sD NSzFhabmN6g+P+fAqh5HKHwcb/fsD17zkViUBj+MzwK68N60m60KS7sWJg28B0jfYqNq qfx4DU0vGf5TnJv3hupfamjbPDiPrjtunSgLYnOH4lrfIkarNUIRzwAsP2BXUPQQlkro 38k6lNeV8PGcr/Wc2UzOPrtB9wWjOWHJZ/cPxomKQ5yVSj4A31jgMaCs3aR808KYn8Ex a3BnfCQycVjd0/g9QwmI0XVaV0CMLKExHfjRFRKmiRYjS4wk7Khmoxq/im0a30hODJHv 4LiQ== X-Gm-Message-State: AOAM532v23utrTXXk+CvFw1PEYNLvYHCCMMNGWBIxiBsm1uQj7W8/9ZX muvtOgs5UWUkWyn6zhKOGJM= X-Google-Smtp-Source: ABdhPJzUb6Hbn3nCAWvKmbxiC3budvc3KkLa0ztl/WI2YqeWF+ibbOF709rbKyjRoMBTHr57v8l7rw== X-Received: by 2002:a7b:cb86:: with SMTP id m6mr8463456wmi.4.1631491695589; Sun, 12 Sep 2021 17:08:15 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q10sm5226603wmq.12.2021.09.12.17.08.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Sep 2021 17:08:15 -0700 (PDT) References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> From: Dmitry Gutov Message-ID: <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> Date: Mon, 13 Sep 2021 03:08:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87y283536t.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hi! On 11.09.2021 04:08, João Távora wrote: > - For LSP, likely "list-only diagnostics" should be used. So basically > Eglot will soon learn to tell Flymake about the "list-only > diagnostics" that it receives from some LSP servers. Once that is > done, M-x flymake-show-project-diagnostics should ideally do most > things that Theodor wants. Does this account for the case of multiple projects? Like, the user might switch between two windows which show buffers from different projects (both, say, are backed by LSP), and they would probably want to see the "global" error list (displayed in a third window) change right away. Or maybe you will have unique "show diagnostics" buffers for every project, to be invoked manually? From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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: Mon, 13 Sep 2021 06:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163151573128437 (code B ref 50244); Mon, 13 Sep 2021 06:49:02 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 06:48:51 +0000 Received: from localhost ([127.0.0.1]:43967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPflr-0007Ob-5Y for submit@debbugs.gnu.org; Mon, 13 Sep 2021 02:48:51 -0400 Received: from mail-pg1-f180.google.com ([209.85.215.180]:33395) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPflo-0007OO-Iy for 50244@debbugs.gnu.org; Mon, 13 Sep 2021 02:48:49 -0400 Received: by mail-pg1-f180.google.com with SMTP id u18so8585031pgf.0 for <50244@debbugs.gnu.org>; Sun, 12 Sep 2021 23:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eaidrzhcBrnZDH2I/Z9HOUuJF7Ea0VVvW+lltKQ/4tY=; b=ZjQNRzHyYMf0PjpAx6RqJd08s+ik0BPqEaSxupahsoyjZBCGoIFoow6NjjAYmJR/Ar HspIMNl2O/YkfDRJyoK0bBCF8mnbEp0XBBsYX+O/gGe4z1G+n3K1wG/zU5RmSlkF+jr1 HRwPvTKtlLsoe9hVqLVhaKkySzqP+qcafwTT0q0neDDwTElJCypYVftnpUELtpzPvjeu OWa/94ryynbQJSdJ5n5FhHKp6ScnPffj6viIqzMWI/74QKd5Dq2In2lFpA9gphgObORh ozNXv1u/0U7bJgTCP6ZK3MOFbcakZylAY2k/ruQElbhZ8YP+kSS6WvomsjVIJCQLs9i/ 3Y5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eaidrzhcBrnZDH2I/Z9HOUuJF7Ea0VVvW+lltKQ/4tY=; b=8NVJcbxHG0JLKhniX/UmoV0Oy+SINi2ecj5MwWCgWsyGdI3dONZsOs8KspYb69hCUo ySI8TZtTsGSmss3QAx6Y1fkfeAeSXjOOXrhhM9Ekc4AWNZEtvQHvuzKjF9Mpt98Aiiat Ye8ql6Du35pxu+Eoo2pVfQ+bPbGk5ZwjsF7j9CT+KuLvp1k9wbvLbZMxa4gloERk+pL8 7fYWEN1EsdKg7ovmb/sKvm+pvp3BpkvGGty3Q72yj1TFIsHrixGFMbYG4DPIZbzkObWV 63IxsPHZoguwgUoxdeSDh8+R5bQK2ZwBba9o2ONvwWwVwnM1ieLqhXRXXTxP1q6OAg+Z Hr8g== X-Gm-Message-State: AOAM530LRJ9pVR+yt2t1fG4cKoBE37x39zkSLov4a3sUiEgTcSqJ9110 Nk6sxVYotH4DkJ5MH6rD2GeM7K/22hi1PvP+bv4= X-Google-Smtp-Source: ABdhPJw7bxh57qNzawKP9ZvF9hPp8LdR/K9H2ta21wx7txNkqXYSVnchGEyeMQzuJCsuvdwoYb15BOmR/4mYj2zhJqg= X-Received: by 2002:a05:6a00:882:b0:416:3ddd:afae with SMTP id q2-20020a056a00088200b004163dddafaemr9873298pfj.72.1631515722655; Sun, 12 Sep 2021 23:48:42 -0700 (PDT) MIME-Version: 1.0 References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> In-Reply-To: <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 13 Sep 2021 07:48:31 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Sep 13, 2021 at 1:08 AM Dmitry Gutov wrote: > Or maybe you will have unique "show diagnostics" buffers for every > project, to be invoked manually? This. But it doesn't seem impossible to make a global diagnostics buffer for every project one has open. Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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: Mon, 13 Sep 2021 18:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163155620821404 (code B ref 50244); Mon, 13 Sep 2021 18:04:01 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 18:03:28 +0000 Received: from localhost ([127.0.0.1]:46776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPqIi-0005ZA-7u for submit@debbugs.gnu.org; Mon, 13 Sep 2021 14:03:28 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:42683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPqIh-0005Yy-3N for 50244@debbugs.gnu.org; Mon, 13 Sep 2021 14:03:27 -0400 Received: by mail-wm1-f45.google.com with SMTP id u19-20020a7bc053000000b002f8d045b2caso591011wmc.1 for <50244@debbugs.gnu.org>; Mon, 13 Sep 2021 11:03:27 -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=OI7AsTXgyUet/acdZCyY3YvOzzclzzPTBcBrYGp+hGI=; b=PAcqGPVxLawanr9uMlIAeVjTxE17CtuAxSrYD305d2LvrqZ0/+XNHzOmbnjm0uFj1c y+YkIbTSV2cGSqgiWjHHitUdasdP+Kjm7mcBiFf1wqDSaJuQy6fo4TH4/EMRqOJuWw0r 2b1xS7If47Ov2D7x5NS56VggdQyLHLOEIi9esC52bG4kRQiqKrS3TrlVUf8V/V4ClEn3 ge49ZB5GOXaKRORBDAi2L8ODa9iAVUMo6n4iMIjGEABvnC7MVYUROjSQysyT7tbMEcZp RywKFgzeMD7hydNSjMtBwhz39+afKnzF+6kaDx3Xv1TBxPtBLoQQJbLf+cldpjH5cQ/p BaQg== 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=OI7AsTXgyUet/acdZCyY3YvOzzclzzPTBcBrYGp+hGI=; b=SeOTDhPYlNuTCvYgHOHPaM4vXRkxHThznawUuwWI5E19ICC4REszy1quberqYT7OFv ahQe1FN4CLOmx5HX7bPFGGnY0VJcXnac2ROQ2v/t71cb2YzjDgsNKb2lu7eF5j4/2mWH 4O4eCSTGX9VVn/apO9poc5SF4ixUtber6hFutQ/xcsV6s7cRcCgTYpKyy3OnPKXx6gzp WSIusI8tGcDwDQPFdb2t0NnbLXa/0o9bsD3bvg6O22hYQ+fn/l7qS2olDCKGqy0WBu50 3n18gTkFF5nnJOT3BB4X7dYyX2RCT9luGU3MdyKbItVGXAijMD28wKCToZg69p2/Jznq etAA== X-Gm-Message-State: AOAM530WXVPUAuiz9CyOMKQ+Wpr5bcsG6ffiILG6t8OEjCMtdem1EnvK +h/woaR14+mPXKDJt3DHAog= X-Google-Smtp-Source: ABdhPJxKlo1mU5s6aa5o091c4I6rzN3CQMlAzDt96SSTbSfOV1QyyBHYkfSlfuPcAs0kdrPyMifr+A== X-Received: by 2002:a1c:ac07:: with SMTP id v7mr12252209wme.160.1631556201198; Mon, 13 Sep 2021 11:03:21 -0700 (PDT) Received: from nadja (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id i27sm7375398wmb.40.2021.09.13.11.03.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Sep 2021 11:03:20 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> Date: Mon, 13 Sep 2021 19:03:19 +0100 In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Mon, 13 Sep 2021 07:48:31 +0100") Message-ID: <87o88w4al4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > On Mon, Sep 13, 2021 at 1:08 AM Dmitry Gutov wrote: > >> Or maybe you will have unique "show diagnostics" buffers for every >> project, to be invoked manually? > > This. But it doesn't seem impossible to make a global diagnostics > buffer for every project one has open. The main changes to flymake.el and its documentation are now ready to push. There are some bugs regarding sorting in the diagnostics listing, and the maybe order and length of columns needs rearranging, but these can be sorted out later. The only outstanding issue preventing me from landing this in main is that I need to bump project.el's version so that the new `project-buffers` API generic function becomes officially available to the new bumped flymake.el version. Dmitry is it OK for me to do so? Here's the trivial patch to project.el. I'm bumping the minor version becasue a new backward-compatible feature was added. I can bump whatever you prefer if you think it's more in-line with the versioning scheme you normally use. diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index ba95ed094e..a6e231b9d6 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1,7 +1,7 @@ ;;; project.el --- Operations on the current project -*- lexical-binding:= t; -*- =20 ;; Copyright (C) 2015-2021 Free Software Foundation, Inc. -;; Version: 0.6.1 +;; Version: 0.7.1 ;; Package-Requires: ((emacs "26.1") (xref "1.0.2")) =20 ;; This is a GNU ELPA :core package. Avoid using functionality that Another important aspect is that I haven't had a change to test this with Eglot, which was one of the main motivators behind this change. The reason is that I don't have easy access to a server which reports diagnostics project wide (I thought clangd did, but I was mistaken). So the only client of the new functionality is the flymake-cc non-LSP backend, for now. Theodor, now would be a good time for you to step in with changes to Eglot that use the new `flymake-list-only-diagnostics` experimental API in flymake.el. Likely, some adjustments will have to be made to both packages. Thanks, Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Sep 2021 19:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Dmitry Gutov Cc: 50244@debbugs.gnu.org, Philipp Stephani Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163156244330931 (code B ref 50244); Mon, 13 Sep 2021 19:48:01 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 19:47:23 +0000 Received: from localhost ([127.0.0.1]:46883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPrvH-00082p-8G for submit@debbugs.gnu.org; Mon, 13 Sep 2021 15:47:23 -0400 Received: from out2.migadu.com ([188.165.223.204]:35035) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPrvD-00082d-6P for 50244@debbugs.gnu.org; Mon, 13 Sep 2021 15:47:21 -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=1631562437; 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=opsfP5AecEXvKWqi8WtWdqYVJQun/4hRpW2wZlUit2Y=; b=gFzkp2bVj9BpF8RYf7JCQmQR7jKb9XPHzTEewnIvlBOIK4ANojtOvLnei+iDVDtrfWyYNz yidiP7C+MfFOu7XF3GaqnnTBGva1H8TgPDEOIJNW0Zt9XHEk/NtX+1ydDAg2ptapuYkCJJ IxFfoCsGWd7XhCYKE8NKfHJXmtgSAM9Wort8NXcsi3bnPLoTJcWFpVjVJ2mYwe+BjwQTIL UJ8E/FnOXGyoWB3RNHu1Rv0r583nhnznqGTY6LdMdUsVYHLRkhRgADHA9ca5toZf0PV2NJ PO04o9bVngwlRWt201uhXHfwaXhf4oWz1yBYC4p6HoPFH+85GBrA1Ovj1eob0A== From: Theodor Thornhill In-Reply-To: <87o88w4al4.fsf@gmail.com> References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <87o88w4al4.fsf@gmail.com> Date: Mon, 13 Sep 2021 21:47:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > > The main changes to flymake.el and its documentation are now ready to > push. There are some bugs regarding sorting in the diagnostics listing, > and the maybe order and length of columns needs rearranging, but these > can be sorted out later. > Very nice, great job! I've been looking through the code the last couple of days. I think it makes sense to treat the list-only diags the way you do here, in that we only need to be able to jump to it, in addition to know that the error is there. One thing I saw while reading and that might not be needed anymore is contained in the diff at the bottom. There might be reasons for this, but I _think_ this should be covered in the &aux variable? > > Another important aspect is that I haven't had a change to test this > with Eglot, which was one of the main motivators behind this change. > The reason is that I don't have easy access to a server which reports > diagnostics project wide (I thought clangd did, but I was mistaken). So > the only client of the new functionality is the flymake-cc non-LSP > backend, for now. > > Theodor, now would be a good time for you to step in with changes to > Eglot that use the new `flymake-list-only-diagnostics` experimental API > in flymake.el. Likely, some adjustments will have to be made to both > packages. > I will absolutely jump at this as quickly as possible. I'm not exactly sure how fast I'll be, since I'm on parental leave right now. How would you want to receive the changes to eglot? As part of this bug, or as a new issue over at GH? I'm fine with either. Considering both flymake and eglot may be affected, maybe this bug is a good place? Again, thanks - now I can soon stop maintaining a trash fork of eglot to get this functionality :) All the best, and I'll get back to you soon! Theo diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el index 83c0b4dd99..543cfe64f4 100644 --- a/lisp/progmodes/flymake.el +++ b/lisp/progmodes/flymake.el @@ -815,8 +815,6 @@ calling convention described in to handle a report even if TOKEN was not expected. REGION is a (BEG . END) pair of buffer positions indicating that this report applies to that region." - (unless state - (error "Can't find state for %s in `flymake--state'" backend)) (cond ((null state) (flymake-error From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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: Mon, 13 Sep 2021 20:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Theodor Thornhill Cc: 50244@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163156345232663 (code B ref 50244); Mon, 13 Sep 2021 20:05:01 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 20:04:12 +0000 Received: from localhost ([127.0.0.1]:46909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsBY-0008Ul-09 for submit@debbugs.gnu.org; Mon, 13 Sep 2021 16:04:12 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:35834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsBV-0008UY-7v for 50244@debbugs.gnu.org; Mon, 13 Sep 2021 16:04:10 -0400 Received: by mail-wr1-f46.google.com with SMTP id i23so16519553wrb.2 for <50244@debbugs.gnu.org>; Mon, 13 Sep 2021 13:04:09 -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; bh=7mRZZ7ie64KosG/9txexEnf2mh59m09kDLiZByb9mQo=; b=FGiXdhVfa2+2OUWGjIuHpBFx1D6fCb+PpsKSP130WoiAqBxJPr40SWQhj1SWJa41Kg ++kJead7dtSgbAEuDodvNxM7+heW6FAWzzvdHltBeOeSIGV9cc/axT9i8vuw7oEM7eq9 GNbKS8zei8DgIKq6PPrkM1EH/X4msQ7wSe/EMaTkq+5vOZ9Pb/aG2fTgZLR/ueWuBK91 D2jXy57DX5RjPtR8mHr/XeahxXwMOJl1XFPnPus/RZidIU5fxhOa5akTx4yD893XhXCw VAW5sw8MMfv0y1aqDcK9Au6Q2ku/Nu6kjKByzxXODxJhhdtUY7KdGVfTHvQcadvwy571 tvTQ== 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; bh=7mRZZ7ie64KosG/9txexEnf2mh59m09kDLiZByb9mQo=; b=iiCnPDi8neJn9ELfdjvLib60eYJqCF8+Z1C3roOzAlijRxg68gNpnfOZRHM4g6PFBf R3iENcSCLdA8qGOo0kLqXXfSd/sFa5npaEMZPXp1jtBoyPVlC2l70MjnnCdKAVZfYO1I xQsV1FuG8KwlCMXUAjsgH5/WGnntpMduon11TE/SklpIxWhA/zFOsPtuLK85kwFhvZS5 eKr9hY3Dy/o6VMO/3zB0Q8OwVvqadnKjB/Lh5B1nkdd4dxke44unnIIVy9VBJxXDMCBf YErBBxfi5xxwWIDwVDPkoisVEbixXeFc2Aupu3reg9CgqhQhwrF+VNui5w2IXoBOU8+o 0CLg== X-Gm-Message-State: AOAM532M+gMZ1Cf0vls0c4Xv5bR4VAsmdu372Zf2/SPnyV8FdV4w1gKq 40fnIuREiNGCu3u5Erh+Qcg= X-Google-Smtp-Source: ABdhPJygP7QSfKTwmyfFWLz7nD5rGE98Aw5N8Wrx1X+c9rjnoOquHJsj1iJ7f8HdUKmWYTAFKhCG8A== X-Received: by 2002:a5d:504f:: with SMTP id h15mr14949908wrt.69.1631563443434; Mon, 13 Sep 2021 13:04:03 -0700 (PDT) Received: from nadja (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id r2sm8862093wrg.31.2021.09.13.13.04.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Sep 2021 13:04:02 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <87o88w4al4.fsf@gmail.com> Date: Mon, 13 Sep 2021 21:04:01 +0100 In-Reply-To: (Theodor Thornhill's message of "Mon, 13 Sep 2021 21:47:15 +0200") Message-ID: <87ilz444zy.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Theodor Thornhill writes: > I will absolutely jump at this as quickly as possible. I'm not exactly > sure how fast I'll be, since I'm on parental leave right now. Congrats And enjoy it (I enjoyed mine very much)! > > How would you want to receive the changes to eglot? As part of this > bug, or as a new issue over at GH? I'm fine with either. Considering > both flymake and eglot may be affected, maybe this bug is a good > place? Yes, it is (but the PR also works). I hope to transfer eglot.el to Emacs core soon anyway. Earlier you said project-wide diagnostics is become a trend with LSP servers. Besides your elm-language-server where you most need this, what other servers are doing this? Maybe I can install one of those for a language I know and start testing this. > diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el > index 83c0b4dd99..543cfe64f4 100644 > --- a/lisp/progmodes/flymake.el > +++ b/lisp/progmodes/flymake.el > @@ -815,8 +815,6 @@ calling convention described in > to handle a report even if TOKEN was not expected. REGION is > a (BEG . END) pair of buffer positions indicating that this > report applies to that region." > - (unless state > - (error "Can't find state for %s in `flymake--state'" backend)) > (cond > ((null state) > (flymake-error Nice catch. From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Sep 2021 20:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.1631563923944 (code B ref 50244); Mon, 13 Sep 2021 20:13:02 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 20:12:03 +0000 Received: from localhost ([127.0.0.1]:46920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsJ8-0000FA-VD for submit@debbugs.gnu.org; Mon, 13 Sep 2021 16:12:03 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:33284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsJ7-0000Eh-5n for 50244@debbugs.gnu.org; Mon, 13 Sep 2021 16:12:01 -0400 Received: by mail-wr1-f47.google.com with SMTP id t18so16575199wrb.0 for <50244@debbugs.gnu.org>; Mon, 13 Sep 2021 13:12:01 -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=1WomJ0sEjvSALywqI7cVs/fuqWgFYb5JJk3+cf/s4pY=; b=XHKB8mz7M3tlik25nKO8Sgt1TvOeO9JuX/DAAevqhFLm0V/2t2Z//ZPov/ClGgQs3t m0ZeWozoHekP2QrdQNj7x3MKidZMYQb3Yy6tBSLQmRAiFHjWf+/iY8wOg8SGouopXh2z XXEVyEh0rBsxXj5Gt4MwTVy6Nz2gT2fQm+cyXz7W86LNknRjca0PihjCATIUTTjhLFv/ WcLEVmp2Q0+MV2AUdBmXBcx9j4Sak+BLPPY4xCn8hjrkhyUkA6QqUwPHXI7oGA/4YlTI sxJR/vRec6w5yhhC68eKAwHebJzHMOYpR1Rjft1I0jPa2lI8U49QPtsZ8I/rF/dBSNsS LUuA== 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=1WomJ0sEjvSALywqI7cVs/fuqWgFYb5JJk3+cf/s4pY=; b=Q5fjEuUmx9j5ReXOiEEDpxeZoVu8zLvG7Pyr9jfT5gdY0C75WLVj27xQ8xm1opYboS L6XPvjnFbKFKRKjuYFidqtYGduKeU748oQE8CIeF9d2P0miL/OZkiuBfZ5pBgzWg7Tbt GRUQvE7jKFu2UEXL6Qg6IG6TL1L8zze7O3ZZn0kOefJnyQ5qQAkpCCg47rSDOTB9g4A5 Mbl7R/wWKF9W2BqzfX0ZnWEfPF3tyGRlYcGo798M63SNnF8dU91HlXLc7Y84Qji881ZT /KnxCagKIiWLuEo9OoAWROfZUdkDbhBlODnF3UiyZ491LeoEPrRh0yD4w87EZcDU9PhV 8U6Q== X-Gm-Message-State: AOAM531ma6sW0SMa98B37XBFs9xhkGIAffltDL3u0QXxOoGIB1xwdHaz wnvjLdJqxy9uB1fBoJA6hEg= X-Google-Smtp-Source: ABdhPJxepT3twVc8H7Tw+fJ2Gn97+LHuZIPT1K8li7ADrijrL96Ipl4IWM7GyAH/9eVi1l0MXR+Kvw== X-Received: by 2002:a5d:66d2:: with SMTP id k18mr14558683wrw.433.1631563915243; Mon, 13 Sep 2021 13:11:55 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id e3sm10598415wrv.18.2021.09.13.13.11.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 13:11:54 -0700 (PDT) References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <87o88w4al4.fsf@gmail.com> From: Dmitry Gutov Message-ID: <061838b7-bf19-b899-f1aa-76760fb35607@yandex.ru> Date: Mon, 13 Sep 2021 23:11:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87o88w4al4.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 13.09.2021 21:03, João Távora wrote: > The only outstanding issue preventing me from landing this in main is > that I need to bump project.el's version so that the new > `project-buffers` API generic function becomes officially available to > the new bumped flymake.el version. Dmitry is it OK for me to do so? Yes, please go ahead. All the latest additions seem stable. Like mentioned previously, I think using project.el for this is probably not ideal (rather, the diagnostic source can decide which diagnostics belong to the current default-directory), but I don't feel up to having an argument about that. From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Sep 2021 20:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.16315644721778 (code B ref 50244); Mon, 13 Sep 2021 20:22:02 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 20:21:12 +0000 Received: from localhost ([127.0.0.1]:46928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsRz-0000Sc-Ra for submit@debbugs.gnu.org; Mon, 13 Sep 2021 16:21:12 -0400 Received: from out0.migadu.com ([94.23.1.103]:40452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsRv-0000SS-Ue for 50244@debbugs.gnu.org; Mon, 13 Sep 2021 16:21:10 -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=1631564466; 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=Uqoqc3yHlpLe3c8tbm2LaUE1Y9b0vRvd3U8i6WrR4RQ=; b=RXYqYfa8JsoPHMh3AXbU/11OaOFVJVT2879k3vpCBe95pq40bwcIMPAHWhvXfstvMFmWtH ho1srZ0K7xh3VcbLf5H+VtydiIu2gfkHR7YcfdGOf7X0owubno1T9DuByIUCxIOzQFv82P g4ava2rChffDHgBd1k830YWD97ccRzVtnO9JuxAHT8+ejyHNGL3f5zg/Zthl7Gm9Nmj+VQ fu6SqBW9OqVl/yojPJTRrHDdoXISpG+5/gTnEEBWgFzmKJ9qLk/HmbU35ChlOsGdolzFzP oz7mKJ/Yw9DpqREjk4DD73EU7sD9ruiD0NVLibPBeV8EaTUwkm3kg5KtlIb/Cg== From: Theodor Thornhill In-Reply-To: <87ilz444zy.fsf@gmail.com> References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <87o88w4al4.fsf@gmail.com> <87ilz444zy.fsf@gmail.com> Date: Mon, 13 Sep 2021 22:21:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Jo=C3=A3o T=C3=A1vora writes: > Theodor Thornhill writes: > >> I will absolutely jump at this as quickly as possible. I'm not exactly >> sure how fast I'll be, since I'm on parental leave right now. > > Congrats And enjoy it (I enjoyed mine very much)! >=20 Thanks! Second time now, only gets better :) > >> How would you want to receive the changes to eglot? As part of this >> bug, or as a new issue over at GH? I'm fine with either. Considering >> both flymake and eglot may be affected, maybe this bug is a good >> place? > > Yes, it is (but the PR also works). I hope to transfer eglot.el to > Emacs core soon anyway.=20=20 > Nice. Consider the lingering PR closed. > Earlier you said project-wide diagnostics is become a trend with LSP > servers. Besides your elm-language-server where you most need this, > what other servers are doing this? Maybe I can install one of those for > a language I know and start testing this. > >From the ones I've used at work, F# [0], C# [1], Rust [2] and Elm [3] all support them. I think the easiest to set up might be the rust one. However, I can help out with settings if needed. I've had to subclass the eglot server to get reliable performance from some of them. > Nice catch. No problem! By the way, I'm testing this version right now, and it seems both faster and more accurate. Not sure why or what exactly happens, but it works flawlessly with eglot atm. Though still without the project buffer. Looking into that a little tonight (election in Norway today, so might stay up a little anyway :P) Theo [0]: https://github.com/fsharp/FsAutoComplete [1]: https://github.com/OmniSharp/omnisharp-roslyn [2]: https://github.com/rust-analyzer/rust-analyzer [3]: https://github.com/elm-tooling/elm-language-server From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Sep 2021 20:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.16315647782269 (code B ref 50244); Mon, 13 Sep 2021 20:27:01 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 20:26:18 +0000 Received: from localhost ([127.0.0.1]:46940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsWw-0000aX-M9 for submit@debbugs.gnu.org; Mon, 13 Sep 2021 16:26:18 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:39582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsWu-0000aK-0z for 50244@debbugs.gnu.org; Mon, 13 Sep 2021 16:26:17 -0400 Received: by mail-wr1-f42.google.com with SMTP id u15so10527598wru.6 for <50244@debbugs.gnu.org>; Mon, 13 Sep 2021 13:26:15 -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=0tYpdispmz4/dSZeTgF+sgICbz2aVExjdbU/Fr6CfAg=; b=mmPf5r0cG6QBdYwubccjSgbNoJT3z67SnWr1rzb1gMprEFtrKopiWeWLqObXwOB7C8 rUPvilcRn/SnnXUVJQcuGVbcIc0K9yVJluHxploc85VOxztHPjKhNT1vAKSlncyrxYBD /7QmKXA46UdcbKls7F6aOGOYz2OOrOwOShDlnyByyVHRt2D3yvmIhZ6ss4qXDNQPqEiT oJ8h4oiu3w45EapuTpn1+bbIzM/2ab5boRCzpWm/6ecfkwlVo2BD26E6epEeZegPUiI8 FrP4VypBY1aS9pAUwEDlkC6/s083KOHG0fLBHgmZXis5lEqnnFI2h6AQx01PLC6lhQTO plIw== 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=0tYpdispmz4/dSZeTgF+sgICbz2aVExjdbU/Fr6CfAg=; b=Bgzc70/Jr9JeDXuPkUrG4p2uPdwbShs0cxCiIrbsH/vjzRTtUjka3VB3AY9sg2rNGr jBdaKMsyhjH79DzmbonNcFgBZHTyhK0U/MeWCyAMxIXjBzKSEqGtkKgwexUzGhMBZ7YN W/pVKPL2YLNBWviGB8w1TSCtb/o0vZw5hsFcRedkRCmDNdyCzSoSNNYF6u0faQ10Dsqs YBHNvtjjYe1PaWrUMvvqbP3thg5GYQejtKFrTLsPNclwU9Nis/HA5LSG//fnvKfrC1Jh aGXXJ7Y/wwvaCNLTgzTJ7o7iy0w3y4Pv0UommtryAns1zST+w4EOIhlzqWAHqTwYyMJ9 8uRw== X-Gm-Message-State: AOAM5304OYsa6Ddro85VzSabmOfRDPexuixBxhjXLxg7KHrOUrXP89k+ 6ahXpBYQyEFZMzXjv5W0QmE= X-Google-Smtp-Source: ABdhPJztW64fptGhist/6hYXRx18pgOd6UJf4QP8WSFNhwv0gQMlJI0zPOkGml50ouNj+cyCJi7Fpw== X-Received: by 2002:adf:e10c:: with SMTP id t12mr14662741wrz.36.1631564770105; Mon, 13 Sep 2021 13:26:10 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n18sm7321133wmc.22.2021.09.13.13.26.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 13:26:09 -0700 (PDT) References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> From: Dmitry Gutov Message-ID: <7c6bb19d-24fa-0875-a25e-8b0739901e0f@yandex.ru> Date: Mon, 13 Sep 2021 23:26:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 13.09.2021 09:48, João Távora wrote: > On Mon, Sep 13, 2021 at 1:08 AM Dmitry Gutov wrote: > >> Or maybe you will have unique "show diagnostics" buffers for every >> project, to be invoked manually? > This. But it doesn't seem impossible to make a global diagnostics > buffer for every project one has open. 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. If global diagnostics are only reported to a particular buffer, perhaps we could do without the global variable by tying refreshes to a callback. That would require an extra hook, however -- like flymake-global-diagnostic-functions. From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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: Mon, 13 Sep 2021 20:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.16315664095088 (code B ref 50244); Mon, 13 Sep 2021 20:54:02 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 20:53:29 +0000 Received: from localhost ([127.0.0.1]:47002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsxF-0001Jz-52 for submit@debbugs.gnu.org; Mon, 13 Sep 2021 16:53:29 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:43679) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPsxD-0001JU-UK for 50244@debbugs.gnu.org; Mon, 13 Sep 2021 16:53:28 -0400 Received: by mail-wr1-f54.google.com with SMTP id b6so16652069wrh.10 for <50244@debbugs.gnu.org>; Mon, 13 Sep 2021 13:53:27 -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=5nqiPTUoqgct7Yv4fM/3tah7TQCuj1Hqdy7aq886vcQ=; b=DQv5pb3GEsGL3Rte2r7hUwjqE5QUJvAHNNzfT8bd+mqtycxAvnva8fhsE37c16wit9 HgAfTDL8pkgeaJc5EXWwwPIbjp0h5vljjez35BadpJMBkCsKAOtmhbZIzERAlo43poXR cN8Bgzc145Wzj5iL08CWJBx12EHEbwMAyUkqINHi0BszGDOpsLNNTjIDs+eGYnnfNInH viq0q+5cAKk5xhXYv8MSmxrDEONyx/qNwAA67AghlecGB6dkwpERJCXnAefnnS8Oyf+J q+XiyvJUBmMl28ASrPnPyaonpFzu0uOcIUczP3xPAKZM4kpxYqnCfuPfZc/45KSo/Hf3 UzVg== 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=5nqiPTUoqgct7Yv4fM/3tah7TQCuj1Hqdy7aq886vcQ=; b=dLPcuvzDhxrA1cNjtb6ozvuLDN34LHcFrl1do5reDn9MHJ7r6z3/BjIaCh5FFo0uwR +uw6vOCPYMBKsCN0khaAeN4JgE2CdvVXw3C5PFRqGwZDp7SyOpNvE3bAWK915RFVaOhy DNCr4LJW21+NHHRM33d9kyf6YZUAUTUmSMdfpD4fPt26m6on6SddgmaXoFn8gTlbRHKH dT+wX0qNNmMcwc28Pz8uQEI/jQf8iloMbRGWgXWHBXuDw3uKHgtlnqsItADtWgcBRlRf yoRe+PoHdAMF0X+7pFAeRwS1A2MnVIzuw0o88Ytxkli8YDoQLB0hZkE4RvIktI1ucsmf v9TQ== X-Gm-Message-State: AOAM531r2sdqjpD3JKHFeW1me/raC/5rTy/zudIir27Iv/nnjegsGMwd GYft2+CNT2weOuX01AMiNDI= X-Google-Smtp-Source: ABdhPJxIpf8LmgnMLY/5LVjr7lqUQzYHjw+xblpxQdiYC6GpMx7nnu5Y+NwvfvKAhzvDbG+RLHHO2w== X-Received: by 2002:a5d:6a81:: with SMTP id s1mr9729973wru.274.1631566401780; Mon, 13 Sep 2021 13:53:21 -0700 (PDT) Received: from nadja (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id z12sm3404408wro.75.2021.09.13.13.53.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Sep 2021 13:53:21 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <7c6bb19d-24fa-0875-a25e-8b0739901e0f@yandex.ru> Date: Mon, 13 Sep 2021 21:53:20 +0100 In-Reply-To: <7c6bb19d-24fa-0875-a25e-8b0739901e0f@yandex.ru> (Dmitry Gutov's message of "Mon, 13 Sep 2021 23:26:06 +0300") Message-ID: <874kao42pr.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 13.09.2021 09:48, Jo=C3=A3o T=C3=A1vora wrote: >> On Mon, Sep 13, 2021 at 1:08 AM Dmitry Gutov wrote: >>=20 >>> Or maybe you will have unique "show diagnostics" buffers for every >>> project, to be invoked manually? >> This. But it doesn't seem impossible to make a global diagnostics >> buffer for every project one has open. > > 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 global diagnostics are only reported to a particular buffer, > perhaps we could do without the global variable by tying refreshes to > a callback. I don't fully understand what you're suggesting, because I don't understand your working concepts. In the new manual section "Foreign and list-only diagnostics", you can read that the new API allows a form of reporting diagnostics for other buffers/files in a way that is tied to a callback. Maybe that that what you mean? Anyway, for the specific of case of Eglot/LSP -- which reports neighboring diagnostics _sporadically_ (i.e. not systematically) -- the "list only" diagnostics seem more suitable. For the purposes that I envisioned (only listing, as the name implies) a global variable also seems suitable. 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. In the meantime, please say if version-bumping project.el is OK. That is the only thing holding up the merge. Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 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 X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163157616519631 (code B ref 50244); Mon, 13 Sep 2021 23:37:01 +0000 Received: (at 50244) by debbugs.gnu.org; 13 Sep 2021 23:36:05 +0000 Received: from localhost ([127.0.0.1]:47068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPvUb-00056Y-Cj for submit@debbugs.gnu.org; Mon, 13 Sep 2021 19:36:05 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:43737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mPvUW-000560-G1 for 50244@debbugs.gnu.org; Mon, 13 Sep 2021 19:36:04 -0400 Received: by mail-wr1-f42.google.com with SMTP id b6so17124267wrh.10 for <50244@debbugs.gnu.org>; Mon, 13 Sep 2021 16:36:00 -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=zy5/phSSSOn3LXS6MRQldBiATl097BVbBDcyLbOeNes=; b=CG3CyFNDXw9EuzOS+Fi136fF/6eM8/dWK50K9mT+zT1s+KGXZQ+Gb29Wbm9gxkZj9x mqzxppCTIeRXpldmhn5UfII1vAZbXzFOtiVBo4lx5jyHtsSbts87d09bkHFulnY2whDr mTS9TNpDsq2lEdVw5hl/jjp0YurdLuvF4I1ot9qAyoHh26DNhKPjO+V4nEykDSluztvP eV/y1FAQQFPASjomF7/tFcpEstgP6sIyKt5SMJfO+ns/Kh0RNj9Rbs0RNFgqKngldlXB jHDbIcHfUycJJLxnVenWx7TSB3ppDp5ERm+YdTsNtVO+yRa3Eh1eQ5pqxGjrfaxIDqGX +qwQ== 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=zy5/phSSSOn3LXS6MRQldBiATl097BVbBDcyLbOeNes=; b=q4aLKFsxahtuEKDaI6lTKZ53RY4qi5zsO4KjLgBoI9X3e84Bnq+6JmBSwFjg9U31Tb zz/kLGvYaOAv/SGHULirBSACM9I/GLoVnVMZ/MpDCG0PSJMEnkN/DTk4XU/GWfIpRvtv aIlK3j+KkM4lGWXNLCAU/eRIM78pxGjfp7oPog21fn4H7aty944j9N3Y0MzHcv2qnJ6t VaCi/6g6ot+416WXLVsiB3ZciqIO9xW7bvM/DGtpsLwnzO6xdjT9qs5ag8f/hktKeNea Ivr6P4bxktuc2KI7Daz3RPcNOvNSsIxMNeLFCQ60knpeS3gdNDPSCQDsfFDIPDXMRdWm HIbA== X-Gm-Message-State: AOAM531as8Uq1IbedemVVQocA2L16C6Fjr2TnISNWOf3xMzJIIQWvY0E 7bGqcpvk0IPGtgbv0483ABc= X-Google-Smtp-Source: ABdhPJzV4kVU5u+T6xUkBmcs1ZsV80e2lbf8/3xRbxHbb4QKf+7fb8RN9S/y4G2zMzEMzNZw8SN1Sg== X-Received: by 2002:a05:6000:1379:: with SMTP id q25mr15154100wrz.280.1631576154459; Mon, 13 Sep 2021 16:35:54 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id w9sm7830715wmc.19.2021.09.13.16.35.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 16:35:54 -0700 (PDT) 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> From: Dmitry Gutov Message-ID: Date: Tue, 14 Sep 2021 02:35:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <874kao42pr.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 13.09.2021 23:53, João Távora 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? > 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. No code, sorry. > In the meantime, please say if version-bumping project.el is OK. That > is the only thing holding up the merge. Already replied to that on 13.09.2021, 23:11: yes, sure, go ahead. From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163160765912361 (code B ref 50244); Tue, 14 Sep 2021 08:21:02 +0000 Received: (at 50244) by debbugs.gnu.org; 14 Sep 2021 08:20:59 +0000 Received: from localhost ([127.0.0.1]:47433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ3gZ-0003DI-Cn for submit@debbugs.gnu.org; Tue, 14 Sep 2021 04:20:59 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:46001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ3gX-0003D6-QG for 50244@debbugs.gnu.org; Tue, 14 Sep 2021 04:20:58 -0400 Received: by mail-wr1-f54.google.com with SMTP id d21so11087680wra.12 for <50244@debbugs.gnu.org>; Tue, 14 Sep 2021 01:20:57 -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=GkbIWqYfm0a3C6ZBQF/wAsjDfCWuu4YkHRJOb0huSo8=; b=KlRwq9wdUBTEQ+6xIa+TRVikDl6ySpeuSB5bO9wbvp9+p0fcnXBbqVb86fyHr0CqqB diSFcSaiyquMjyGd8AjH4XW6SCd4ODLPQfjoBAHcUHKI6Cutf2Qxz7731+lzT8aa+sb4 PaL/e0Z1exxNhGvK/jOpflZSMV2uhA3y9/iO0sh3WrM2fq946jlVn4xxmrVEwUSc364b 4mcAAF6gOJGjpiEcKASreCsTS3duJrHAu1sNObDb4FGotPCQHrMRA8dONi9j2QFiAzY5 /2ohWsObFy4rvB6YbIsJ4Hi/b9h1FPdNbHxz3eZXovR8iDrbxlwEp6avnb7tJUki+JSF tGig== 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=GkbIWqYfm0a3C6ZBQF/wAsjDfCWuu4YkHRJOb0huSo8=; b=w/B9F4A5uVWzLFbFEm9xwHOB9TiZfSXzXadZw0Ybo1eSWqmdwJAPTZdz+e/eTEZr+2 dyMMNybczFnlY5PBtvPd6r0dE1LZFEhC+QjVMeWG0tgsK79Y+GSfJ65eBRVoVnB4Uh1S SyZuAshD3BtdZWpUR0jh618i2e6B1L8Xliksvdxx8GuPoGjyIF+a/riIOowtrxcFiCtV cUr/YatgHJnBCppqjUw2EnRbhC2zKRO9mRvY7PzNNYCX+cfuvKgdifKhmZXIhiT0UqFg fsQeINyuRpgJCerNB2hHt1RhfeCEUkjOQHTw21XEXbhqlAB/ysmbpda6ON8o26i/TJbr k+Lg== X-Gm-Message-State: AOAM531hYrJm32dk5WYJ2WMAsdP3Ri7eYzg3QFuRoLs9JC8Jb051fO0a frrG/ZAsoehtyoGh16AWf1k= X-Google-Smtp-Source: ABdhPJyoR9kloDPLBgZkND8P6qSLOcxUHsYrzQPoKIP+egA0PpwqB6VoYd1AJ2fWwne1lZFPgpTtPg== X-Received: by 2002:adf:e643:: with SMTP id b3mr17329937wrn.299.1631607651766; Tue, 14 Sep 2021 01:20:51 -0700 (PDT) Received: from nadja (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id x21sm397089wmi.15.2021.09.14.01.20.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 01:20:51 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <87o88w4al4.fsf@gmail.com> <061838b7-bf19-b899-f1aa-76760fb35607@yandex.ru> Date: Tue, 14 Sep 2021 09:20:50 +0100 In-Reply-To: <061838b7-bf19-b899-f1aa-76760fb35607@yandex.ru> (Dmitry Gutov's message of "Mon, 13 Sep 2021 23:11:51 +0300") Message-ID: <87wnnj36vx.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 13.09.2021 21:03, Jo=C3=A3o T=C3=A1vora wrote: >> The only outstanding issue preventing me from landing this in main is >> that I need to bump project.el's version so that the new >> `project-buffers` API generic function becomes officially available to >> the new bumped flymake.el version. Dmitry is it OK for me to do so? > > Yes, please go ahead. All the latest additions seem stable. Thanks. > Like mentioned previously, I think using project.el for this is > probably not ideal (rather, the diagnostic source can decide which > diagnostics belong to the current default-directory), Yes, it can, and it does (have you read the change?) In fact the diagnostic source knows nothing about projects. But at a certain point, someone will have to know about "projects", because the request is not for "default-directory-wide diagnostics", it's for project-wide diagnostics. I don't know what better library to use for segregating diagnostics into projects other than project.el: it works quite well, to be frank. That said, if even that bothers you, the uses of project.el in flymake.el are minimal and are the simplest part of this whole job. If you or someone can get rid of them and somehow keep a coherent M-x flymake-show-project-diagnostics command, it's not unthinkable. Maybe you'd prefer it renamed to M-x flymake-show-aggregated-diagnostics to get the "project" word out of there. But frankly I think the current command name and implementation is really spot-on what was requested here. At least it seems to make sense to Theodor and me as a user. Indeed, I even thought that flymake-show-project-diagnostics could go into the 'C-x p' map. But users can do that easily if they want to, so I won't argue for that now. Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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 X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163160901614760 (code B ref 50244); Tue, 14 Sep 2021 08:44:01 +0000 Received: (at 50244) by debbugs.gnu.org; 14 Sep 2021 08:43:36 +0000 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 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 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) 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) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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> Date: Tue, 14 Sep 2021 09:43:26 +0100 In-Reply-To: (Dmitry Gutov's message of "Tue, 14 Sep 2021 02:35:51 +0300") Message-ID: <87o88v35u9.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Theodor Thornhill Cc: 50244@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163160942923736 (code B ref 50244); Tue, 14 Sep 2021 08:51:01 +0000 Received: (at 50244) by debbugs.gnu.org; 14 Sep 2021 08:50:29 +0000 Received: from localhost ([127.0.0.1]:47496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ497-0006Al-0Q for submit@debbugs.gnu.org; Tue, 14 Sep 2021 04:50:29 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:36542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ495-0006AZ-T2 for 50244@debbugs.gnu.org; Tue, 14 Sep 2021 04:50:28 -0400 Received: by mail-wr1-f54.google.com with SMTP id g16so18944237wrb.3 for <50244@debbugs.gnu.org>; Tue, 14 Sep 2021 01:50:27 -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=5oVA34Hv+V11N9jGI/S4Ux9qs0vqqpA8Aa+0ci2sWDc=; b=UEEwwJUyYfy/QoGrVsOv+3UU7QtPVE/TYnpNNZS3ieaLtcY4gInz2pPC5xd8kjK1i0 a+/ypk12xTBpKJkg/7XXJhpRiL9AtSdnJvCP1fyABvdjKVzMWJeRXIPBqQfuCuYmt48r oeEk9hxz/iMpbdmTHxK0oe+BEXbtlc0iOHv7YzpHtI0rFJX6k8jNU/G3l/pkcv2pEvho V4jKs1EjYq1JQYC4aGe/vg+1Zmxowd7NF0lKMkMjtG1ZzdiB+D7v+pzuov3/TIou7hXN pGRrWpQZVYo2+LIyhAb9+8ycZ0eK/13yhcYlCHNZnM+KXy6R87CvoJNm78Nh2G3GCsXE MwsQ== 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=5oVA34Hv+V11N9jGI/S4Ux9qs0vqqpA8Aa+0ci2sWDc=; b=Vv1vLtkNoSX43cl4FeORK/J942rTEovea2om+cgRglgmq/PYKyiAH5J1j3g0rnLCXi UqH6Hh20xzNLe6bbmSIgnQ7R+QZBsMtUAGSp9AaGb36tR5VhSsPhxtE5VhQHg5cxnVaT EdhRjr0xsOqo8Vl6E4QzwkBsWL6wWq5eock8WWlXkJ23Xvc4EaTFQA4u4VwA73Ee4SOe 1Zkw94Cx1aaP99rPmbJZzRmx4d7f5mGG2I4GLCQ/zImS0ohvKGNXCoZOx7BQUL0hWeKG sstV2YnTkKUPmVCbWnPG9whi3Gh835NBrbx9IDZD68mgHcnDLtZ5OHLKuDbPf0tWATE3 iFkA== X-Gm-Message-State: AOAM531MOJE90nLJu7bCYHTb5HRlR+mpriC0wpcqUW+Xu3w1loel5Tr7 XFKCu6UDmCxGOw8W9Gr4mbg= X-Google-Smtp-Source: ABdhPJz1mYzd2gxAOzZP1KBDKpGWn4CgVGCV/T/841wlYpCCWV49ITHjYaqSdQUUReO7UUSOX5vQpQ== X-Received: by 2002:a5d:4f91:: with SMTP id d17mr17637816wru.285.1631609422059; Tue, 14 Sep 2021 01:50:22 -0700 (PDT) Received: from nadja (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id m29sm10371207wrb.89.2021.09.14.01.50.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 01:50:21 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <87o88w4al4.fsf@gmail.com> <87ilz444zy.fsf@gmail.com> Date: Tue, 14 Sep 2021 09:50:12 +0100 In-Reply-To: (Theodor Thornhill's message of "Mon, 13 Sep 2021 22:21:03 +0200") Message-ID: <87k0jj35iz.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Theodor Thornhill writes: > Jo=C3=A3o T=C3=A1vora writes: > >> Theodor Thornhill writes: >>> I will absolutely jump at this as quickly as possible. I'm not exactly >>> sure how fast I'll be, since I'm on parental leave right now. >> Congrats And enjoy it (I enjoyed mine very much)! >=20 > Thanks! Second time now, only gets better :) I second that, too ;-) >> Yes, it is (but the PR also works). I hope to transfer eglot.el to >> Emacs core soon anyway.=20=20 > Nice. Consider the lingering PR closed. Thanks, and sorry it took me so long to get to it. > From the ones I've used at work, F# [0], C# [1], Rust [2] and Elm [3] > all support them. I think the easiest to set up might be the rust one. > However, I can help out with settings if needed. I've had to subclass > the eglot server to get reliable performance from some of them. Thanks. I think I'll try rust-analyzer as I've been meaning to anyway. Perhaps make it the default Rust server for Eglot. > By the way, I'm testing this version right now, and it seems both faster > and more accurate. Not sure why or what exactly happens, but it works > flawlessly with eglot atm. Hmmm that's good, but also odd: i didn't do any performance/accuracy improvements that I know of. If anything, because I changed so much code, I would suspect the inverse: i.e. bugs. Please keep an eye out. Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Sep 2021 09:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163161131026787 (code B ref 50244); Tue, 14 Sep 2021 09:22:02 +0000 Received: (at 50244) by debbugs.gnu.org; 14 Sep 2021 09:21:50 +0000 Received: from localhost ([127.0.0.1]:47535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ4dS-0006xy-9X for submit@debbugs.gnu.org; Tue, 14 Sep 2021 05:21:50 -0400 Received: from out2.migadu.com ([188.165.223.204]:36661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ4dP-0006xn-8P for 50244@debbugs.gnu.org; Tue, 14 Sep 2021 05:21:49 -0400 Date: Tue, 14 Sep 2021 11:21:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1631611305; 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=uPHVuExrXtE3F9xDZL7pk804F5N37DnFUV0DACVHAsE=; b=Z5TY8UDXidA/uB6V/ku90+8qZJfq3KcWzIE2n8iZj7m80OwiZ6ouo7TFcqr+LWHyqm5fs3 Qz6JdyT+0ZfxsbaOzRMUFLY/hgL9kR68q+QVJJkGOvujOogvo+CChDXQd/wC+mjdonVmCf 40xT9EnTJgpYUYJgbA5NITnlFjOxgN8hk1xb3nvIrgPWm7uvArdd/jlFyp5tJ42/++W+1e BA85GbUZKR5cOggKKhovg/hclyWtjCM1SKDYSvCxvyzgTEn1spjXkFF1DO/JtxpGzE/3wS 4kjZgDGvx2GCaCY+p0heJsWheon27SOijXYTPzeo7kptyQmzHrpeCS1sRtDAYw== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill In-Reply-To: <87k0jj35iz.fsf@gmail.com> 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> Message-ID: <46AA4768-F628-49C5-A933-8ED43814CAC9@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > >>> Yes, it is (but the PR also works)=2E I hope to transfer eglot=2Eel t= o >>> Emacs core soon anyway=2E =20 >> Nice=2E Consider the lingering PR closed=2E > >Thanks, and sorry it took me so long to get to it=2E > No worries! >> From the ones I've used at work, F# [0], C# [1], Rust [2] and Elm [3] >> all support them=2E I think the easiest to set up might be the rust on= e=2E >> However, I can help out with settings if needed=2E I've had to subclas= s >> the eglot server to get reliable performance from some of them=2E > >Thanks=2E I think I'll try rust-analyzer as I've been meaning to anyway= =2E >Perhaps make it the default Rust server for Eglot=2E > Absolutely, the community seems to have moved on=2E >> By the way, I'm testing this version right now, and it seems both faste= r >> and more accurate=2E Not sure why or what exactly happens, but it work= s >> flawlessly with eglot atm=2E > >Hmmm that's good, but also odd: i didn't do any performance/accuracy >improvements that I know of=2E If anything, because I changed so much >code, I would suspect the inverse: i=2Ee=2E bugs=2E Please keep an eye o= ut=2E I might be wrong, of course=2E My implementation could also have some def= ects, also=2E By the way- these list only diagnostics do in fact happen on each keystrok= e in the mentioned servers=2E Not just on the first load=2E Would this me= an the foreign variant is more correct to use? =20 Theo =20 From unknown Fri Aug 15 20:55:34 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Subject: bug#50244: closed (Re: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el) Message-ID: References: <87ee9r2xwt.fsf@gmail.com> <87bl5hm5qj.fsf@gmail.com> X-Gnu-PR-Message: they-closed 50244 X-Gnu-PR-Package: emacs Reply-To: 50244@debbugs.gnu.org Date: Tue, 14 Sep 2021 11:35:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1631619302-8447-1" This is a multi-part message in MIME format... ------------=_1631619302-8447-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #50244: 28.0.50; Support project-wide diagnostics reports in flymake.el which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 50244@debbugs.gnu.org. --=20 50244: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D50244 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1631619302-8447-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 50244-done) by debbugs.gnu.org; 14 Sep 2021 11:34:56 +0000 Received: from localhost ([127.0.0.1]:47731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ6iG-0002Bt-2h for submit@debbugs.gnu.org; Tue, 14 Sep 2021 07:34:56 -0400 Received: from mail-wr1-f53.google.com ([209.85.221.53]:34624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ6i9-0002BX-U2 for 50244-done@debbugs.gnu.org; Tue, 14 Sep 2021 07:34:55 -0400 Received: by mail-wr1-f53.google.com with SMTP id m9so19693132wrb.1 for <50244-done@debbugs.gnu.org>; Tue, 14 Sep 2021 04:34:49 -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; bh=Qm8LEx0xyKowqlS06XtbneP3IRcxcPdZG/LvWlvOmVA=; b=gC2zmGW/9sKS2aHf1ZlaRqyFxIsxw8Ms+Z5gLNwvbtKU/iYpoIe7CFEwRIF8DAnsV7 /4xQdEZtxE6inMgmGwRMSXzwsYgqz/3NXvLj46NUYPzWMvAfGtjJjVEQOt8SCIvowD6G oX+eYEOlAYEEaOAF7BjGs2wPdK0fOIMi4jUdt4KPZrIcGjdjptIR6i7IYzdLIDMivCmj b/CNHLRQVVr5m7PEajS/4n5E9axw99qhekUZhA7omg26wp1Vo8UHt3DteiGNzV/H5rLX 6lUYxrfzSZ2E1kV/Xg61WkgJWKyPnTre0bQ+d+s8Q0dceAkhLk2zBt3qRvJWtMqaH7Mf /oDA== 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; bh=Qm8LEx0xyKowqlS06XtbneP3IRcxcPdZG/LvWlvOmVA=; b=rxrh9XFvzmpavKZHICs8zwiqvK62zUG0guG9aOXjshKUd73yjFWTrTRPnAtBw8UrNn AauOWRpp9jP/smZUAB7w/UJgcY7jqpECVVKwvPt7mvGeJnt6s3W3XaxVRk8bJBBIg+Kh dz51h6KJsVuomDBmM3WKwlwXhnrag93/mhu/CAP/h4ciGTQ3uyqarLihJ7/GmuN7Wgc+ tg3FE3ovENRcc3BRoL1bHRnRDogtRti7Lz6O2tDZ5t9Qnc67HtJEMyOZJ9f3V2I//cM3 7M2qAUR+IXc+gXQJbIRElfh+YunZvwNtzG8eoVGAX6H7XCZRFl796nIHYWyaQ/dYxHnS 6mrQ== X-Gm-Message-State: AOAM530ySKeYk6rECYiGk95yF7V5L27xLu3t0fYXjpU3a8lmLVFiGTpM Rr/kWNPIBDICuwCoSUGX74A= X-Google-Smtp-Source: ABdhPJzwfIrlV3r6SZRG5EIj7mxctyDnpCtothniVJVcQw4hdS8B/v+Q5Re4e8EOsjzZHwpWA/bJqg== X-Received: by 2002:a5d:650b:: with SMTP id x11mr18089038wru.350.1631619284013; Tue, 14 Sep 2021 04:34:44 -0700 (PDT) Received: from nadja (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id m3sm13278827wrg.45.2021.09.14.04.34.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 04:34:43 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Theodor Thornhill Subject: Re: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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> Date: Tue, 14 Sep 2021 12:34:42 +0100 In-Reply-To: <46AA4768-F628-49C5-A933-8ED43814CAC9@thornhill.no> (Theodor Thornhill's message of "Tue, 14 Sep 2021 11:21:36 +0200") Message-ID: <87ee9r2xwt.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50244-done Cc: 50244-done@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Theodor, I've now pushed this to master, so I'm marking the bug done. But we can keep discussing the Eglot patch here (or in another bug, or in Eglot's tracker, as you prefer...) Theodor Thornhill writes: >>Thanks. I think I'll try rust-analyzer as I've been meaning to anyway. >>Perhaps make it the default Rust server for Eglot. > Absolutely, the community seems to have moved on. Actually I did still try with `rls` since that was most handy and it also provides diagnostics for other files on startup. So I tested it with rls and got decent results (see Eglot patch). > By the way- these list only diagnostics do in fact happen on each > keystroke in the mentioned servers. Not just on the first load. > Would this mean the foreign variant is more correct to use? Yes, it would, indeed. I don't know if _every_ server operates like that, though. But doesn't matter. Are you saying that in your server, making a modification to any file always brings in diagnostics for all other files, too? Anyway, I've tested a bit with Eglot and flymake-list-only-diagnostics and it seems to do the right thing (mostly). I attach the Eglot patch which you can use as starting point. diff --git a/eglot.el b/eglot.el index 7ebc422..d036a75 100644 --- a/eglot.el +++ b/eglot.el @@ -1386,6 +1386,11 @@ Doubles as an indicator of snippet support." (font-lock-ensure) (string-trim (filter-buffer-substring (point-min) (point-max)))))) +(defun eglot--diag-type (severity) + (cond ((<= severity 1) 'eglot-error) + ((= severity 2) 'eglot-warning) + (t 'eglot-note))) + (define-obsolete-variable-alias 'eglot-ignored-server-capabilites 'eglot-ignored-server-capabilities "1.8") @@ -1788,8 +1793,7 @@ COMMAND is a symbol naming the command." diag-spec (setq message (concat source ": " message)) (pcase-let - ((sev severity) - (`(,beg . ,end) (eglot--range-region range))) + ((`(,beg . ,end) (eglot--range-region range))) ;; Fallback to `flymake-diag-region' if server ;; botched the range (when (= beg end) @@ -1808,16 +1812,26 @@ COMMAND is a symbol naming the command." (point-at-eol (1+ (plist-get (plist-get range :end) :line))))))) (eglot--make-diag (current-buffer) beg end - (cond ((<= sev 1) 'eglot-error) - ((= sev 2) 'eglot-warning) - (t 'eglot-note)) + (eglot--diag-type severity) message `((eglot-lsp-diag . ,diag-spec))))) into diags finally (cond (eglot--current-flymake-report-fn (eglot--report-to-flymake diags)) (t (setq eglot--unreported-diagnostics (cons t diags)))))) - (jsonrpc--debug server "Diagnostics received for unvisited %s" uri))) + (cl-loop + with path = (expand-file-name (eglot--uri-to-path uri)) + for diag-spec across diagnostics + collect (eglot--dbind ((Diagnostic) message severity source) diag-spec + (setq message (concat source ": " message)) + (eglot--make-diag path (cons 1 1) nil ; cons 1 1 bcs lazy... + (eglot--diag-type severity) + message)) + into diags + finally + (setq flymake-list-only-diagnostics + (assoc-delete-all path flymake-list-only-diagnostics #'string=)) + (push (cons path diags) flymake-list-only-diagnostics)))) (cl-defun eglot--register-unregister (server things how) "Helper for `registerCapability'. ------------=_1631619302-8447-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 29 Aug 2021 00:53:18 +0000 Received: from localhost ([127.0.0.1]:55183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mK94Y-0006Pe-B5 for submit@debbugs.gnu.org; Sat, 28 Aug 2021 20:53:18 -0400 Received: from lists.gnu.org ([209.51.188.17]:56650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mK94W-0006PS-DS for submit@debbugs.gnu.org; Sat, 28 Aug 2021 20:53:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39372) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mK94V-0003uE-Ts for bug-gnu-emacs@gnu.org; Sat, 28 Aug 2021 20:53:15 -0400 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:38597) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mK94U-0006mm-6e for bug-gnu-emacs@gnu.org; Sat, 28 Aug 2021 20:53:15 -0400 Received: by mail-wr1-x42a.google.com with SMTP id u16so16638058wrn.5 for ; Sat, 28 Aug 2021 17:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=GSA/SjyYHCyH0SwZr94dAyPnUKaLZqkKta4uvWKYfBc=; b=g7gui8q8PYIqe7GyW2uOy6P9csxpUVV2uRjYVfJFS0X3ODl4bEXSlNEitiE6Z8ve7a c3jV7vhdmDePBPl7L5rshm0X0g/zBVtrB2Q4tL6Qr5vTYFuwWv9mLia8USvDRkz7+Wug M9LBtYsh1gyv6NdYdscDcmZUIczIwJ4MDhQmKB+u+shGHooSuh9znm4vPfl7R7nBxZoK Bqv78v8k3MB7NIdO+Nn0Fn0i0O3+59wvLkoLpMJBZInMoG7P8K06ecs85pC7JrT/HkUe YccD65Llllb904FZ51cu8XCk+QsAgssOWHDo+K+1mDC2jN8RwoHnNxQECa+38NroQjzR Jnfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=GSA/SjyYHCyH0SwZr94dAyPnUKaLZqkKta4uvWKYfBc=; b=tgetEj3Vo1MqPsCT8VYEfSsVufA8eyMjN1bSzBu+ZW8CPZ3NoV/QbEEFUd+sHLwPwB Fd+qB/DxmsFFFpTXMTWCec5vVh4Lgbj6EH9AEiQUl8P9BchBpLp4VxDWTJFreEsITHdk VzgA3c24bhoHFHR6Ew7AQn7MZNrkDPBh2S+LIJCRpzQw4aE2EjJUWbyiNxgpChjgZo5p tus2yM7b7BstHT1C36K/FTZKutS9/C8QdkZuMlTDlHoSVpTClRMxfyfpS/B15pKZbdJx 2vCYH6cgYdKKmCvoeOJZhN1JvMv0Hlc9QvwFXwmp1+L+Ecj9Ud4awncyDhW2yEnH7j/i JSCA== X-Gm-Message-State: AOAM533nUZENMpuh3RXJYRvvjKmmPAyEF/FN9L7dIkSqnsZd3vTd/3HA axPJ4pK1e4qrU91p9PVOLqU= X-Google-Smtp-Source: ABdhPJyepuMdhVMYhF0IQaX+yho5GvX38w1A51mvc7tH0rUNVmsdzxuIXja5kgULm+OyjEAdRRLAXg== X-Received: by 2002:adf:9f05:: with SMTP id l5mr17858423wrf.188.1630198391548; Sat, 28 Aug 2021 17:53:11 -0700 (PDT) Received: from krug (a94-133-103-226.cpe.netcabo.pt. [94.133.103.226]) by smtp.gmail.com with ESMTPSA id y6sm12910910wrm.54.2021.08.28.17.53.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Aug 2021 17:53:11 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: bug-gnu-emacs@gnu.org, Theodor Thornhill , p.stephani2@gmail.com Subject: 28.0.50; Support project-wide diagnostics reports in flymake.el Date: Sun, 29 Aug 2021 01:53:08 +0100 Message-ID: <87bl5hm5qj.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is coming from: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D34418 https://github.com/joaotavora/eglot/pull/640 In the first, Philip wonders why the BUFFER argument to flymake-make-diagnostic is mostly ignored. In the second, Theodor requests that the Eglot LSP client manage and display the diagnostics reported by the LSP server not only for the current buffer being edited, but for other buffers or files. The connection between the two will hopefully become apparent soon. Normally, diagnostics reports are emitted by diagnostic backend for a single file, usually as a result of a change performed shortly before in the buffer visiting that file. This is true for most LSP servers when acting as Flymake backends. But some LSP servers seem to take this opportunity to also "piggy-back" diagnostics for other files, in a kind of "side-band signal". Other servers yet will sometimes report diagnostics upfront for all files in a given project, whether visited by a buffer or not. Theodor's pull request handles this side band signal for LSP specifically in the Eglot client, but it contains some twists and turns that should not be taken in Eglot. This functionality should be supported in Flymake. * What kind of new API support for Flymake backends is needed for this? This is the good news: I think not much. The helper function flymake-make-diagnostic, used by Flymake backends such as Eglot's, already supports a BUFFER first argument, but, as the manual states. =20=20=20 Currently, it is unspecified behavior to make diagnostics for buffers other than the buffer that the Flymake backend is responsible for. =20=20=20 My idea is to make it specified. As floated in bug#34418 I think the idea of generalizing the argument to mean BUFFER-OR-FILE is decent and sufficient. * What kind of infrastructure changes in Flymake are needed for this? That's more complicated: substantial, but not insane. Here's a top-level plan: the current buffer-local variable flymake--backend-state should probably first become a global hash table indexed by buffer, which should be mostly indistinguishable from a buffer-local var. If that works, then it should be possible to store the piggy-backed diagnostics in (1) file-indexed entries to that global hash table, for files which are not being visited by buffers. It should also be possible to add (2) buffer-indexed entries to it for buffers which, though live, don't have Flymake properly activated or don't have that specific piggy-backing backend in their running backend list. These new types of entries will likely not contain the full-blown flymake--backend-state structs, i.e. they will be missing the 'running', 'reported-p' and 'disabled' slots. All they will have is a non-nil list 'diags'. If, for situations (1) or (2), we discover that a "proper" buffer-indexed entry already exists in the global hash table, we must decide if the information in them should take priority. I'm not sure of the answer to this yet. Anyway, in flymake--handle-report is where the recording of information should happen. We can have a look at the current aforementioned "unspecified" behavior: (setq new-diags (cl-remove-if-not (lambda (diag) (eq (flymake--diag-buffer diag) (current-buff= er))) report-action)) (As we can see, the current "unspecification" is just ignoring reports for BUFFERs other than the current.) * In what new UI parts is the augmented information to be useful? Currently, I see only one place, the diagnostic listing buffer obtained by M-x flymake-show-diagnostics-buffer. That buffer is usually associated with only one source buffer (flymake--diagnostics-buffer-source). Now it should start listing all the diagnostics for buffers or files known to belong to the same project, using 'project.el' functionality for that. Jo=C3=A3o ------------=_1631619302-8447-1-- From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Sep 2021 12:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244-done@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov Received: via spool by 50244-done@debbugs.gnu.org id=D50244.163162217221428 (code D ref 50244); Tue, 14 Sep 2021 12:23:02 +0000 Received: (at 50244-done) by debbugs.gnu.org; 14 Sep 2021 12:22:52 +0000 Received: from localhost ([127.0.0.1]:47867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ7Se-0005ZX-FK for submit@debbugs.gnu.org; Tue, 14 Sep 2021 08:22:52 -0400 Received: from out2.migadu.com ([188.165.223.204]:24440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ7Sa-0005ZM-TQ for 50244-done@debbugs.gnu.org; Tue, 14 Sep 2021 08:22:51 -0400 Date: Tue, 14 Sep 2021 14:22:42 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1631622167; 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=pSiRXhluNs++BuCYY18Tsn383Yxicem1cNJzh6xpl1A=; b=UamYNoJHc+KRUVBFB/yT01rgk7IJhbNkTgbXQhBqo83Xv8hogH8VZ2mARARoIvtzR1v4N8 NYdbUDQljKZq6jVc2XCnsp6fIox0DtRPkQpBTue/EiSglaWCTKjGCEfgCMZALlU/tzzzUh lBh0kKkcGXkJDMAWF8KwiF52hWW/T1aKEy4nPe26cpXLNUWyXvS2NvVEF4p4+Xm7Sg/x1L WyDYVfixJjVcmrDLbGPHVfKpn1rZ+PEUhR2O4E8UdGz5bxwMjaXNdIM/EJEa1FAZhferk6 3NS0E7wq5eoSrKJsvrozmcbUktlOesHb2mpSIifTHEm1WOolRTfGwjVh3sdB1g== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill In-Reply-To: <87ee9r2xwt.fsf@gmail.com> 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> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 14 September 2021 13:34:42 CEST, "Jo=C3=A3o T=C3=A1vora" wrote: >Hi Theodor, > >I've now pushed this to master, so I'm marking the bug done=2E But we >can keep discussing the Eglot patch here (or in another bug, or in >Eglot's tracker, as you prefer=2E=2E=2E) > Great=2E >Theodor Thornhill writes: > >>>Thanks=2E I think I'll try rust-analyzer as I've been meaning to anywa= y=2E >>>Perhaps make it the default Rust server for Eglot=2E >> Absolutely, the community seems to have moved on=2E > >Actually I did still try with `rls` since that was most handy and it >also provides diagnostics for other files on startup=2E So I tested it >with rls and got decent results (see Eglot patch)=2E > >> By the way- these list only diagnostics do in fact happen on each >> keystroke in the mentioned servers=2E Not just on the first load=2E >> Would this mean the foreign variant is more correct to use? > >Yes, it would, indeed=2E I don't know if _every_ server operates like >that, though=2E But doesn't matter=2E Are you saying that in your serve= r, >making a modification to any file always brings in diagnostics for all >other files, too? > Yeah=2E For any edit in any file, _all_ diagnostics for everything gets re= -sent=2E I've made the assumption earlier that everything is to be flushed= every time=2E=20 >Anyway, I've tested a bit with Eglot and flymake-list-only-diagnostics >and it seems to do the right thing (mostly)=2E I attach the Eglot patch >which you can use as starting point=2E > Thank you! I'll follow up on this tonight if time permits :) >diff --git a/eglot=2Eel b/eglot=2Eel >index 7ebc422=2E=2Ed036a75 100644 >--- a/eglot=2Eel >+++ b/eglot=2Eel >@@ -1386,6 +1386,11 @@ Doubles as an indicator of snippet support=2E" > (font-lock-ensure) > (string-trim (filter-buffer-substring (point-min) (point-max)))))) >=20 >+(defun eglot--diag-type (severity) >+ (cond ((<=3D severity 1) 'eglot-error) >+ ((=3D severity 2) 'eglot-warning) >+ (t 'eglot-note))) >+ > (define-obsolete-variable-alias 'eglot-ignored-server-capabilites > 'eglot-ignored-server-capabilities "1=2E8") >=20 >@@ -1788,8 +1793,7 @@ COMMAND is a symbol naming the command=2E" > diag-spec > (setq message (concat source ": " message)) > (pcase-let >- ((sev severity) >- (`(,beg =2E ,end) (eglot--range-region range))) >+ ((`(,beg =2E ,end) (eglot--range-region range))) > ;; Fallback to `flymake-diag-region' if server > ;; botched the range > (when (=3D beg end) >@@ -1808,16 +1812,26 @@ COMMAND is a symbol naming the command=2E" > (point-at-eol > (1+ (plist-get (plist-get range :end) := line))))))) > (eglot--make-diag (current-buffer) beg end >- (cond ((<=3D sev 1) 'eglot-error) >- ((=3D sev 2) 'eglot-warnin= g) >- (t 'eglot-note)) >+ (eglot--diag-type severity) > message `((eglot-lsp-diag =2E ,di= ag-spec))))) > into diags > finally (cond (eglot--current-flymake-report-fn > (eglot--report-to-flymake diags)) > (t > (setq eglot--unreported-diagnostics (cons t diag= s)))))) >- (jsonrpc--debug server "Diagnostics received for unvisited %s" uri))= ) >+ (cl-loop >+ with path =3D (expand-file-name (eglot--uri-to-path uri)) >+ for diag-spec across diagnostics >+ collect (eglot--dbind ((Diagnostic) message severity source) diag-s= pec >+ (setq message (concat source ": " message)) >+ (eglot--make-diag path (cons 1 1) nil ; cons 1 1 bcs lazy= =2E=2E=2E >+ (eglot--diag-type severity) >+ message)) >+ into diags >+ finally >+ (setq flymake-list-only-diagnostics >+ (assoc-delete-all path flymake-list-only-diagnostics #'string= =3D)) >+ (push (cons path diags) flymake-list-only-diagnostics)))) >=20 > (cl-defun eglot--register-unregister (server things how) > "Helper for `registerCapability'=2E > > > From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Sep 2021 22:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.16318307944662 (code B ref 50244); Thu, 16 Sep 2021 22:20:01 +0000 Received: (at 50244) by debbugs.gnu.org; 16 Sep 2021 22:19:54 +0000 Received: from localhost ([127.0.0.1]:56771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQzjW-0001D7-B9 for submit@debbugs.gnu.org; Thu, 16 Sep 2021 18:19:54 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:42905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQzjU-0001Cs-15 for 50244@debbugs.gnu.org; Thu, 16 Sep 2021 18:19:53 -0400 Received: by mail-wr1-f51.google.com with SMTP id q11so11851337wrr.9 for <50244@debbugs.gnu.org>; Thu, 16 Sep 2021 15:19:51 -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=u/H959Hnn7AvFsWNbYtH33jJ44rBujgKz5bdIx/meAM=; b=FAz2WZmjkklyW2wMkvi+NQN/zwBoya6yTxCWeX5WoVYar+DmMULpM58n8sLStanjmV zd7m7Eo06JUMbeKBTe/nxwG+JXilJEiLBC0P4aZ8SWK+qIAQ2VAJp/Xd9KV2QRK0yvKo rx5VnRRZ0XwUkiM3GvOCe7m8r/p46NVpy9XjrFxNY102DHOGya/WTpX1xlPr1gT8igcY wEYHQj5VrRdzeBL1lgFIboi3jz4p3tbUgEfpYy98cXvtvTX/YTNNJLLCO7tpVFjd/HIP PBQi3VJA9nLksZAB9j7iDWLDWqOcL7MdhPySjepn4ahz3A1iuNVIcQ6SATsj98OKH2Ll rm9w== 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=u/H959Hnn7AvFsWNbYtH33jJ44rBujgKz5bdIx/meAM=; b=11rmM/FnHZA9tzNZMIMgRzGNpNLXHdkK2wo6XEBVlPawihYC65yU3dHR57BOYLfwy/ 22ydIUu+2oXtetWMfmFdFkY2HDzxBH55SQ6G1aljJCIAWRbSOhgsHIN+G0anXoleIMrt kfgoNgRoWUXwEr+Mf7FJ/WWqQDQw9qZTwqlK7QrEwtT7pJRuTFoRVbAXs7zsPxQBILv2 b9TRxXPS0f2+6Gdv5r6pDzdDsMYfRob8aFsjEcdNuhhf0+iU9KuHnJrhqoRga5pjfQ8L yMOUsnaQu+aM4NcTbViCOc2YQl4cfL5Sf/LLHE7B+nSdUngoQszPh2A7MSlJ8R+PTNy0 YuAA== X-Gm-Message-State: AOAM532PxNs+tGAlCYsSGoatSY1VWVr/kVRfnORKfFXGbyvADs2dZy8L VlQ2gDUTPZwy9paxDP/UHgc= X-Google-Smtp-Source: ABdhPJw/+Q2ZeeB9R8QHKoGtMPhpGorQxzHsL2UdO3G+wJrrTiDG9BiXQnob0RGWmznUHLs6g/WjRw== X-Received: by 2002:a5d:6486:: with SMTP id o6mr8245784wri.193.1631830786141; Thu, 16 Sep 2021 15:19:46 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id o13sm5479582wri.53.2021.09.16.15.19.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Sep 2021 15:19:45 -0700 (PDT) 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> From: Dmitry Gutov Message-ID: Date: Fri, 17 Sep 2021 01:19:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87o88v35u9.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 14.09.2021 11:43, João Távora wrote: > Dmitry Gutov writes: > >> On 13.09.2021 23:53, João Távora 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. It's a judgment call, but that seems fairly involved for a public API. 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. 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. >>> 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. 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. > "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. The situation where we have a backend which returns errors only for some of the "other" files but not all, is not something I considered, but if that is indeed an important use case, no argument from me. UI-wise, though, they could probably work as the "global" source of errors anyway, right? Unless the same projects usually also have a project-wide list of errors coming from another source. But in the former case the syntax check would be triggered by e.g. editing and saving the current file -- and you should be able to both see the list of errors in the current file, and then the list of all remaining errors. 'M-x flymake-show-diagnostics-buffer' could have a slightly different view in this case: first show the errors for the current buffer, and then the errors in other 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. 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. 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. 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. > 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? >> 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, 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. From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Sep 2021 22:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.16318312635422 (code B ref 50244); Thu, 16 Sep 2021 22:28:02 +0000 Received: (at 50244) by debbugs.gnu.org; 16 Sep 2021 22:27:43 +0000 Received: from localhost ([127.0.0.1]:56775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQzr5-0001PN-FN for submit@debbugs.gnu.org; Thu, 16 Sep 2021 18:27:43 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:36683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQzr3-0001P7-VW for 50244@debbugs.gnu.org; Thu, 16 Sep 2021 18:27:42 -0400 Received: by mail-wr1-f46.google.com with SMTP id g16so11890579wrb.3 for <50244@debbugs.gnu.org>; Thu, 16 Sep 2021 15:27:41 -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=DZ8y3M51azuZ5Kf2cr/BfSsPKWmb/RDFbZxfjJ3uetc=; b=o3bn836WEdGKl/fyZ2cPpqAkB3eJGcu4M60lfvWUCJNEyBtGKBN9CWcOD0Hygx+XkQ nqpYS45XpqgGKrXt0S8XcVn/apCFSXpK7lsfYkNuk4OD0i9U//+KAcXch/HBydRNqPei NtiMwDPUle/cuoC2Nl0JSasqHHyCkvU4f11u5ct2Le1WUPD1WohuV8NE2NPcdWY5DMpZ J1vqgMkLYorpeBVrYZHAS2eADz400PwPB8ul5VBICeaKBehtF85dzpfNifwFwd79r3Zd JW4Mx6NrrJoyUjRKHV9wU+wTuiHqctabD8tmitgtKB1pr9WRZWbjd2B9lq4Yc8zrqISw g7HQ== 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=DZ8y3M51azuZ5Kf2cr/BfSsPKWmb/RDFbZxfjJ3uetc=; b=syXcYjUk/aEP+4o/n9NgTsKtBJ5XObsTycV8WMQBSbjVDrwEF0B4TSGrD1jTcXBvJi yBJK145ydP+pePtB+i0F3TW8ycmCRXkEPyc2kU2ZSrp3iYOgw+8JkNRbJTK367u7F5p3 2UjVgBwA56D9h3wxyZSBS2+8qR782RK7k+OvH6s0LNyNI5yqnM2r3Or5qDkktXXVhR4h 4gATQxkjNXwGTGk0TLhMdLg2VbhLvbVrAbSyOEK96wfxlUJx7i+6XjaXOoOBLuf1Se04 ryPzvB6Ws2WoIR7LYkYud3lfSCLQpPKkn8bXLNa+sn34TWRAbalfc86ouTphg2ueIIyV KgUg== X-Gm-Message-State: AOAM533JDOCOHpISTdWSQZUYGs6FusyqJet/0xHr5Hp4RxRDIWjZj7YK QZOXqjx5tr4+Wnkb1+eMjPI= X-Google-Smtp-Source: ABdhPJwAVpfqaHsJ1gB9YQFXmSNb8Y6+Hn1SWWJjdfWAyrxh3Qb3nsNTKogR+ERsuNHfltTrKSWSSQ== X-Received: by 2002:a5d:4985:: with SMTP id r5mr8731343wrq.397.1631831256177; Thu, 16 Sep 2021 15:27:36 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id v17sm4687745wrr.69.2021.09.16.15.27.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Sep 2021 15:27:35 -0700 (PDT) References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <87o88w4al4.fsf@gmail.com> <061838b7-bf19-b899-f1aa-76760fb35607@yandex.ru> <87wnnj36vx.fsf@gmail.com> From: Dmitry Gutov Message-ID: <09d26dd2-b27b-1f5b-b1b7-a72330ec6dd7@yandex.ru> Date: Fri, 17 Sep 2021 01:27:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87wnnj36vx.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 14.09.2021 11:20, João Távora wrote: >> Like mentioned previously, I think using project.el for this is >> probably not ideal (rather, the diagnostic source can decide which >> diagnostics belong to the current default-directory), > Yes, it can, and it does (have you read the change?) In fact the > diagnostic source knows nothing about projects. But at a certain point, > someone will have to know about "projects", because the request is not > for "default-directory-wide diagnostics", it's for project-wide > diagnostics. I don't know what better library to use for segregating > diagnostics into projects other than project.el: it works quite well, to > be frank. When I said "belong to default-directory", I didn't mean "reside inside". I meant "all diagnostics that, in the opinion of the diagnostics source, relate to the specified default-directory". Basically all diagnostics belonging to the project which default-directory belongs to (with implicit assumption that default-directory can uniquely identify the project). > Indeed, I even thought that flymake-show-project-diagnostics could go into the 'C-x p' map. But users can do that easily if they want to, so I won't argue for that now. Uh, maybe. I was thinking we'd rather add a new keymap (in the spirit of Flycheck's 'C-c !') with Flymake-related commands. Then the "aggregated diagnostics" could be on its own button, or they could even be displayed by 'M-x flymake-show-diagnostics-buffer'. From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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 X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163183538917363 (code B ref 50244); Thu, 16 Sep 2021 23:37:01 +0000 Received: (at 50244) by debbugs.gnu.org; 16 Sep 2021 23:36:29 +0000 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 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 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) 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) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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> Date: Fri, 17 Sep 2021 00:36:17 +0100 In-Reply-To: (Dmitry Gutov's message of "Fri, 17 Sep 2021 01:19:42 +0300") Message-ID: <87wnngdrf2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163183546317486 (code B ref 50244); Thu, 16 Sep 2021 23:38:02 +0000 Received: (at 50244) by debbugs.gnu.org; 16 Sep 2021 23:37:43 +0000 Received: from localhost ([127.0.0.1]:57860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR0wp-0004Xy-Dt for submit@debbugs.gnu.org; Thu, 16 Sep 2021 19:37:43 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:35671) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR0wl-0004Xj-6R for 50244@debbugs.gnu.org; Thu, 16 Sep 2021 19:37:41 -0400 Received: by mail-wr1-f47.google.com with SMTP id i23so12105308wrb.2 for <50244@debbugs.gnu.org>; Thu, 16 Sep 2021 16:37:39 -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=FnIWKYnLUT49IDejHgWP9SUVwg83GhvsmHxtN+otl1w=; b=Cr8O4+SFoLMTClD8QhPGJt7JwuZM1VSfQLruaYp/j2/Hqk8tB+I1gJmVTtqFeITEIY 6p+thQF1fs+kNPsyjlu/A0kR2d72C/tGeindbHmRTwoDttuCpTu0oFVZ38X9gs1N3wsT 7LLE0JbeTJSbKq0iKSVmaxvqrMTosZa97d5zrEeKQ96336vs2kaApIQvV94wD14BfEYI wbG4ZR+03Z5/qJQx1SRmwrpRMtzTdZKnSVRiyJJ7dbA2gl2MZPr3cmkjTJPOvXAKKhgO DkpiRzjeAkA4jBfYJneWHiY9wIhYmVyKU8eOQtmERQQI7QeZvKdoHGqZDvBgmFv5rs6P o4rA== 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=FnIWKYnLUT49IDejHgWP9SUVwg83GhvsmHxtN+otl1w=; b=3cWelo0J99bfQo4Z9Q5OwGmUrTm9B8IfNOehr2OH/RQUHYP+zQYwiapaRHq31GVZXz phPCzM92F6HqfTFBPQZJKmH4/qCKyR/CuBlKfF/ceAwoKfeO1QnqWKz8TxmpGTv7rHZi zlirLJk5jPVY4LzPS5iHZktIak6SSKu3qigN/a1cpm+OFJXCne42nReRLa9sN/48MH+I kArI9rUXBUPu5Ea7WgvDzqudXTlfXZshVYgLuzO3ejSkYRyAhOFEPjk/6UGhJ5IgDiw5 YzaU3sS+8pKYSdfUF7DY/gdeW+C3s+dTukzeYpk3+7rprJCrnql6E9C0ofzoPwO+J0t7 AdPg== X-Gm-Message-State: AOAM530d83jVWmeCtTyO/jgWu9lNC0eQNAwv+/vUQUV6nMFcn64mwsAC ITS6jquAqKrZUIfr5H4qFgE= X-Google-Smtp-Source: ABdhPJwQuOKv7xeLGV2LcB8s/HiWi+2yGkBUJqWom3hwVZCkJtIAoNZf51dLoEVVsTD61HcvcmG/rA== X-Received: by 2002:adf:c14c:: with SMTP id w12mr8886674wre.115.1631835453388; Thu, 16 Sep 2021 16:37:33 -0700 (PDT) Received: from krug (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id u6sm5697638wrp.0.2021.09.16.16.37.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 16:37:32 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87bl5hm5qj.fsf@gmail.com> <87y283536t.fsf@gmail.com> <41cd4854-d162-bc6c-900e-96a4245e2c59@yandex.ru> <87o88w4al4.fsf@gmail.com> <061838b7-bf19-b899-f1aa-76760fb35607@yandex.ru> <87wnnj36vx.fsf@gmail.com> <09d26dd2-b27b-1f5b-b1b7-a72330ec6dd7@yandex.ru> Date: Fri, 17 Sep 2021 00:37:31 +0100 In-Reply-To: <09d26dd2-b27b-1f5b-b1b7-a72330ec6dd7@yandex.ru> (Dmitry Gutov's message of "Fri, 17 Sep 2021 01:27:33 +0300") Message-ID: <87sfy4drd0.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > When I said "belong to default-directory", I didn't mean "reside > inside". I meant "all diagnostics that, in the opinion of the > diagnostics source, relate to the specified default-directory". > > Basically all diagnostics belonging to the project which > default-directory belongs to (with implicit assumption that > default-directory can uniquely identify the project). I think I answered this is my other email. >> Indeed, I even thought that flymake-show-project-diagnostics could go > into the 'C-x p' map. But users can do that easily if they want to, so > I won't argue for that now. > > Uh, maybe. I was thinking we'd rather add a new keymap (in the spirit > of Flycheck's 'C-c !') with Flymake-related commands. Then the > "aggregated diagnostics" could be on its own button, or they could > even be displayed by 'M-x flymake-show-diagnostics-buffer'. OK. Could be. Won't argue that now. Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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 X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163192796710598 (code B ref 50244); Sat, 18 Sep 2021 01:20:01 +0000 Received: (at 50244) by debbugs.gnu.org; 18 Sep 2021 01:19:27 +0000 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 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 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) 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) 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> From: Dmitry Gutov Message-ID: Date: Sat, 18 Sep 2021 04:19:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87wnngdrf2.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) 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. From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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 X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 50244@debbugs.gnu.org, Philipp Stephani , Theodor Thornhill Received: via spool by 50244-submit@debbugs.gnu.org id=B50244.163195917015142 (code B ref 50244); Sat, 18 Sep 2021 10:00:02 +0000 Received: (at 50244) by debbugs.gnu.org; 18 Sep 2021 09:59:30 +0000 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 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 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) 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) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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> Date: Sat, 18 Sep 2021 10:59:20 +0100 In-Reply-To: (Dmitry Gutov's message of "Sat, 18 Sep 2021 04:19:16 +0300") Message-ID: <87r1dmcih3.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 22 06:59:33 2021 Received: (at control) by debbugs.gnu.org; 22 Oct 2021 10:59:33 +0000 Received: from localhost ([127.0.0.1]:59584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mdsGr-0004DQ-Go for submit@debbugs.gnu.org; Fri, 22 Oct 2021 06:59:33 -0400 Received: from out0.migadu.com ([94.23.1.103]:43999) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mdsGm-0004D8-HZ for control@debbugs.gnu.org; Fri, 22 Oct 2021 06:59:31 -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=1634900367; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=fOeXbvGBblvMpCn0/78h++2N+fVijXDmoJvX9ZFHGvY=; b=hY+NlZn3+cmiqWIDcSnJ5MzIjgXdJBbZCNVjnidcfRvh1KZ+0Fw49y676zk7eE1eggquVp vtq9LRxDfrQdJx4Y1P3CzokJsuOTBjRXQ2S5YYVCr6ZLmfw4HtIO0yiLK7PG3p7r7QIHJr eOwJgeSYIg0cZwnnpMj3MaeShD1jnlVfQCQhE/tfaI1VilZT3+vAM2YX69i6o0Qo1qt64D LutU39BymPpdezfIzs8/Wyr4u4yVU5xFSCxz2ZttXgovEshC8kMAUM6ID8rUdhMQKtvrGu LsI3Q8spToIseuGYH+NQR6s1XD/l1ZUpKSbMDI89eTeYkyljI3oy/hryVWg0Xw== From: Theodor Thornhill To: control@debbugs.gnu.org Subject: unarchive 50244 Date: Fri, 22 Oct 2021 12:59:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) unarchive 50244 From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Oct 2021 19:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244-done@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov Received: via spool by 50244-done@debbugs.gnu.org id=D50244.163501693913087 (code D ref 50244); Sat, 23 Oct 2021 19:23:02 +0000 Received: (at 50244-done) by debbugs.gnu.org; 23 Oct 2021 19:22:19 +0000 Received: from localhost ([127.0.0.1]:37325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meMaw-0003P1-Uk for submit@debbugs.gnu.org; Sat, 23 Oct 2021 15:22:19 -0400 Received: from out0.migadu.com ([94.23.1.103]:48031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meMar-0003Oq-UC for 50244-done@debbugs.gnu.org; Sat, 23 Oct 2021 15:22:17 -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=1635016932; 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=Fdvs/vOw+0jXm5B241OPbQxGfCAzfUlAsqC+w1VntLs=; b=uegVPQY8gpLsF8b/2t6E7FXkRDGfvRINHkG1SOhtQm8AnksfqiKHAVQc4wVIztf+iSC4Rr 1OkT4lC8XCK+ie8+plF/oRnuFm33WwNY+O3uFBG2/58S5axQq8uenkQWEqDCaO6nyBQ9Mb F+2yoAkCwklqJh+g7wvy5h3qznbdGOSIC92HqAj1p7HIz3/jpGnyjC9b7bdR6WzdcDqcGT akalz7LAcXT3DPWzGA568sufxwp68AQ253v+wrWFBF4Lk5F3HX+8EdtLgX3FhYV48iLexS GM+iAI0R75pzG/xNrDRVkffMOwOuStd9Hhn7CCMDXWt22sSdHjuGPlnoM9S2VQ== From: Theodor Thornhill In-Reply-To: <87ee9r2xwt.fsf@gmail.com> 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> Date: Sat, 23 Oct 2021 21:22:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Jo=C3=A3o! (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 :)) 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? - 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? - 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...) - 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. I'd love to get your thoughts on this :) Theodor diff --git a/eglot.el b/eglot.el index bf9cf25..47c7b74 100644 --- a/eglot.el +++ b/eglot.el @@ -1776,9 +1776,14 @@ COMMAND is a symbol naming the command." (_server (_method (eql telemetry/event)) &rest _any) "Handle notification telemetry/event") ;; noop, use events buffer =20 +(defun eglot--diag-type (severity) + (cond ((<=3D severity 1) 'eglot-error) + ((=3D severity 2) 'eglot-warning) + (t 'eglot-note))) + (cl-defmethod eglot-handle-notification (server (_method (eql textDocument/publishDiagnostics)) &key uri diagnos= tics - &allow-other-keys) ; FIXME: doesn't respect `eglot-strict-mode' + &allow-other-keys) ; FIXME: doesn't respect `eglot-strict= -mode' "Handle notification publishDiagnostics" (if-let ((buffer (find-buffer-visiting (eglot--uri-to-path uri)))) (with-current-buffer buffer @@ -1787,9 +1792,7 @@ COMMAND is a symbol naming the command." collect (eglot--dbind ((Diagnostic) range message severity source) diag-spec (setq message (concat source ": " message)) - (pcase-let - ((sev severity) - (`(,beg . ,end) (eglot--range-region range))) + (pcase-let ((`(,beg . ,end) (eglot--range-region range)= )) ;; Fallback to `flymake-diag-region' if server ;; botched the range (when (=3D beg end) @@ -1807,17 +1810,29 @@ COMMAND is a symbol naming the command." (setq end (point-at-eol (1+ (plist-get (plist-get range :end) :li= ne))))))) - (eglot--make-diag (current-buffer) beg end - (cond ((<=3D sev 1) 'eglot-error) - ((=3D sev 2) 'eglot-warning) - (t 'eglot-note)) - message `((eglot-lsp-diag . ,diag-s= pec))))) + (eglot--make-diag + (current-buffer) beg end + (eglot--diag-type severity) + message `((eglot-lsp-diag . ,diag-spec))))) into diags finally (cond (eglot--current-flymake-report-fn (eglot--report-to-flymake diags)) (t (setq eglot--unreported-diagnostics (cons t diags)= ))))) - (jsonrpc--debug server "Diagnostics received for unvisited %s" uri))) + (cl-loop + with path =3D (expand-file-name (eglot--uri-to-path uri)) + for diag-spec across diagnostics + collect (eglot--dbind ((Diagnostic) range message severity source) di= ag-spec + (setq message (concat source ": " message)) + (let* ((start (plist-get range :start)) + (line (1+ (plist-get start :line))) + (char (1+ (plist-get start :character)))) + (eglot--make-diag path (cons line char) nil (eglot--diag-= type severity) message))) + into diags + finally + (setq flymake-list-only-diagnostics + (assoc-delete-all path flymake-list-only-diagnostics #'string= =3D)) + (push (cons path diags) flymake-list-only-diagnostics)))) =20 (cl-defun eglot--register-unregister (server things how) "Helper for `registerCapability'. From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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, 23 Oct 2021 20:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Theodor Thornhill Cc: 50244-done@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov Received: via spool by 50244-done@debbugs.gnu.org id=D50244.163502056119155 (code D ref 50244); Sat, 23 Oct 2021 20:23:02 +0000 Received: (at 50244-done) by debbugs.gnu.org; 23 Oct 2021 20:22:41 +0000 Received: from localhost ([127.0.0.1]:37416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meNXM-0004yr-Ew for submit@debbugs.gnu.org; Sat, 23 Oct 2021 16:22:41 -0400 Received: from mail-pj1-f42.google.com ([209.85.216.42]:36531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meNXJ-0004yc-8X for 50244-done@debbugs.gnu.org; Sat, 23 Oct 2021 16:22:38 -0400 Received: by mail-pj1-f42.google.com with SMTP id v1-20020a17090a088100b001a21156830bso1792726pjc.1 for <50244-done@debbugs.gnu.org>; Sat, 23 Oct 2021 13:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Oe9eE1C7b00tBRXk6YCPeHcfygaCT20oRUQZCpP48q8=; b=hMtcf4sZWxp8eFOTmslovD1gM5ijE+y6P73BE83ThxG8UeBl1KTXdJMY8WI++fZA0+ loxwNXaR7RODXBQeDiDjIE9MamXRuDvvBQLlwdKhuQw2yZXbJTkO6PIjZecgOLKnlYb5 rxPLaSvTN9MF2aqEoIne0/SETsR5s3IR3PTMNU0xgJN+5Z0JrLh3GdxejXy4anZjt3of rmE6M98mft+l0d24BdsVS1WcEFShnj4bjKSbetVt1UfnVLUrUBF3b/Zdu38tmHXxVp3h VMsoFUs4/vAW6Th7+jQMr+LIdgLXb0qrpVSb2PZZbVVuotUP79hNAVQBC/Y9ezQL8Vmo 8PFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Oe9eE1C7b00tBRXk6YCPeHcfygaCT20oRUQZCpP48q8=; b=G/uGBbBwEA3eo/NQWZMd4WWu8b6Wa8m4n97wekAimd4TEtLLsvLs/VoX5HUYSpBNjR flJpfvCgXyIEDgdApcMBcKVk4pvcctWWeS51/fl6Q3euiwsDVqsFTD+x7zKmqQadwehP Fjn++XJWhi1yPXF8Wsn2t7c7F3Vw5VBaYoduzsIp9TlEUkn0GkhLnNDBdjhVhJ9bwdsQ 8DAl5SglznmdxeM8OFvOwsG5L4s/HfTJsea0y/CmYZKc/Ox8gs48QM+rsv1dvnsd6Ymi PwED8fnA7ojLWItHHxmjG112QgWRBmYYieA3PfkGFNKW1FlyT2WS56dQIrvhn+7FodXB cFcA== X-Gm-Message-State: AOAM5334HE5CYKEFQLkdgEbm25WPMCtSFkLlGFwI1922NumIxsKpBLhU 0K8d1j+m9v4btFxNaoMEZ6UYKt2aB+DEMt/j1qc= X-Google-Smtp-Source: ABdhPJy+JEDi63DzRwVAi1xAh5eJX8yuQDhUVHW8OMCfmtmSAC9XspT4qh/hRBae81Ge8PRn9t1qJWnOa+4JHY3HKks= X-Received: by 2002:a17:90b:17c3:: with SMTP id me3mr23911216pjb.70.1635020551230; Sat, 23 Oct 2021 13:22:31 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Sat, 23 Oct 2021 21:22:20 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Oct 23, 2021 at 8:22 PM Theodor Thornhill wrote= : > (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. > 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. > - 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. > - 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. 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. 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. > - 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 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/Flymak= e actually checking). So using the LSP range and converting it to flymake-make-diagnostic's protocol seems ok. > 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. Do consider patches/changes to flymake.el as well. This new mechanism is very new, it's possible it needs some tweaks. Jo=C3=A3o From unknown Fri Aug 15 20:55:34 2025 X-Loop: help-debbugs@gnu.org Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el 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 X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 50244-done@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov Received: via spool by 50244-done@debbugs.gnu.org id=D50244.163502220830198 (code D ref 50244); Sat, 23 Oct 2021 20:51:02 +0000 Received: (at 50244-done) by debbugs.gnu.org; 23 Oct 2021 20:50:08 +0000 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 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== From: Theodor Thornhill In-Reply-To: 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> Date: Sat, 23 Oct 2021 22:50:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: theo@thornhill.no X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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