unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: "João Távora" <joaotavora@gmail.com>,
	50244@debbugs.gnu.org, theo@thornhill.no, p.stephani2@gmail.com
Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el
Date: Mon, 30 Aug 2021 02:27:52 +0300	[thread overview]
Message-ID: <8dfca367-baa8-c4ae-8e6b-8ca41d5a63d6@yandex.ru> (raw)
In-Reply-To: <87bl5hm5qj.fsf@gmail.com>

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?





  reply	other threads:[~2021-08-29 23:27 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 [this message]
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
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=8dfca367-baa8-c4ae-8e6b-8ca41d5a63d6@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=50244@debbugs.gnu.org \
    --cc=joaotavora@gmail.com \
    --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).