unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 50244@debbugs.gnu.org, Philipp Stephani <p.stephani2@gmail.com>,
	Theodor Thornhill <theo@thornhill.no>
Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el
Date: Tue, 14 Sep 2021 09:20:50 +0100	[thread overview]
Message-ID: <87wnnj36vx.fsf@gmail.com> (raw)
In-Reply-To: <061838b7-bf19-b899-f1aa-76760fb35607@yandex.ru> (Dmitry Gutov's message of "Mon, 13 Sep 2021 23:11:51 +0300")

Dmitry Gutov <dgutov@yandex.ru> writes:

> 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.

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ão





  reply	other threads:[~2021-09-14  8:20 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-29  0:53 bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el João Távora
2021-08-29 23:27 ` Dmitry Gutov
2021-08-30  7:00   ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-30  8:46   ` João Távora
2021-09-11  1:08 ` João Távora
2021-09-13  0:08   ` Dmitry Gutov
2021-09-13  6:48     ` João Távora
2021-09-13 18:03       ` João Távora
2021-09-13 19:47         ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-13 20:04           ` João Távora
2021-09-13 20:21             ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-14  8:50               ` João Távora
2021-09-14  9:21                 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-14 11:34                   ` João Távora
2021-09-14 12:22                     ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-23 19:22                     ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-23 20:22                       ` João Távora
2021-10-23 20:50                         ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-13 20:11         ` Dmitry Gutov
2021-09-14  8:20           ` João Távora [this message]
2021-09-16 22:27             ` Dmitry Gutov
2021-09-16 23:37               ` João Távora
2021-09-13 20:26       ` Dmitry Gutov
2021-09-13 20:53         ` João Távora
2021-09-13 23:35           ` Dmitry Gutov
2021-09-14  8:43             ` João Távora
2021-09-16 22:19               ` Dmitry Gutov
2021-09-16 23:36                 ` João Távora
2021-09-18  1:19                   ` Dmitry Gutov
2021-09-18  9:59                     ` João Távora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnnj36vx.fsf@gmail.com \
    --to=joaotavora@gmail.com \
    --cc=50244@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=p.stephani2@gmail.com \
    --cc=theo@thornhill.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).