From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: sbaugh@janestreet.com, 71504@debbugs.gnu.org
Subject: bug#71504: 30.0.50; FR: Fix suggestions ("quick fix") for Flymake diagnostics
Date: Sun, 07 Jul 2024 13:50:35 +0200 [thread overview]
Message-ID: <m1bk39zaic.fsf@dazzs-mbp.home> (raw)
In-Reply-To: <868qyd32ih.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 07 Jul 2024 13:44:22 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: sbaugh@janestreet.com, 71504@debbugs.gnu.org
>> Date: Sun, 07 Jul 2024 10:53:12 +0200
>>
>> >> From: Eshel Yaron <me@eshelyaron.com>
>> >> Cc: Eli Zaretskii <eliz@gnu.org>, 71504@debbugs.gnu.org
>> >> Date: Thu, 27 Jun 2024 20:15:37 +0200
>> >>
>> >> Spencer Baugh <sbaugh@janestreet.com> writes:
>> >>
>> >> > For example, maybe we want to have a command which can accept fixes
>> >> > output by a process running in M-x compile. Baking the UI into flymake
>> >> > would make that impossible, wouldn't it?
>> >>
>> >> I don't think adding a command for fixing the diagnostic at point should
>> >> preclude any other developments or explorations. It's a useful thing to
>> >> have, and many Flymake backends have the needed data readily available.
>> >>
>> >> > So before any change in flymake I would like to see much more
>> >> > exploration of "fix" UIs which are genuinely flymake-independent.
>> >>
>> >> Flymake shows diagnostics, and "fixing" is what we do to diagnostics.
>> >> What would be the benefit of a Flymake-independent UI for fixing the
>> >> diagnostics that Flymake already shows?
>> >
>> > The benefit would be that we will be able to use that UI when "fixes"
>> > are shown in, for example, the *compilation* buffer.
>>
>> It'd be good to enhance compilation buffers as well, but this feature
>> request is about interaction with Flymake diagnostics, that are shown in
>> the diagnosed buffer: I'd like to have a standard way to act on (fix)
>> the diagnostic at point.
>
> I frankly don't understand what you are saying here. Several people
> opined that we should take a broader view on the fixes and how to
> handle them, but you insist that Flymake should have its own solution?
No. I only insist that there should be a command for fixing the
Flymake diagnostic at point. If it's part of a "broader solution",
that's swell.
> IOW, the "fixes" diagnostic shown by Flymake is not just diagnostic,
> it's a suggestion to make some change in the source code.
I think there is a misunderstanding here: it's not about specific
diagnostics which represent fixes, this is about enriching
(potentially) all diagnostics with backend-provided fix suggestions,
and adding a command that applies such fixes. For example, with my
implementation I use the same command for fixing checkdoc, shellcheck
and LSP diagnostics.
> So supporting that cannot be separated from the more general concept
> of making changes proposed by some external tool. Or what am I
> missing?
IIUC, I think I agree. In my implementation, Flymake delegates the
application of the code changes to another library, that includes a
general purpose function for applying code changes.
> Or maybe this is a simple misunderstanding: what do you mean by
> "acting on diagnostic at point"
Applying a suggested code change that resolves the diagnostic.
> , and how could such an act be indifferent to what and how is fixed?
A single command should let you fix diagnostics from different sources
(backends). It doesn't need to be indifferent, just consistent.
Does that make sense?
next prev parent reply other threads:[~2024-07-07 11:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 8:43 bug#71504: 30.0.50; FR: Fix suggestions ("quick fix") for Flymake diagnostics Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-27 7:32 ` Eli Zaretskii
2024-06-27 13:35 ` Spencer Baugh
2024-06-27 18:15 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-06 7:50 ` Eli Zaretskii
2024-07-07 8:53 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-07 10:44 ` Eli Zaretskii
2024-07-07 11:50 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-07-07 14:28 ` Eli Zaretskii
2024-07-11 5:43 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-11 6:08 ` Eli Zaretskii
2024-07-11 7:28 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-12 6:35 ` Eli Zaretskii
2024-07-16 9:49 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-16 10:28 ` Eli Zaretskii
2024-07-16 15:19 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-16 15:33 ` Eli Zaretskii
2024-07-16 21:27 ` Spencer Baugh
2024-07-17 11:51 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-24 16:40 ` Spencer Baugh
2024-07-24 17:44 ` João Távora
2024-07-25 9:04 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
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=m1bk39zaic.fsf@dazzs-mbp.home \
--to=bug-gnu-emacs@gnu.org \
--cc=71504@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=me@eshelyaron.com \
--cc=sbaugh@janestreet.com \
/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).