GNU bug report logs -
#66041
30.0.50; Should 'flymake-note-echo' inherit from 'compilation-info'?
Previous Next
Reported by: Jim Porter <jporterbugs <at> gmail.com>
Date: Sun, 17 Sep 2023 04:43:02 UTC
Severity: minor
Found in version 30.0.50
Done: João Távora <joaotavora <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Thu, 21 Sep 2023 22:40:20 +0100
with message-id <CALDnm51DCfc45Sy4zAoLnyPMfseFbLbCzBBiM8guQMc=HMhWNw <at> mail.gmail.com>
and subject line Re: bug#66041: 30.0.50; Should 'flymake-note-echo' inherit from 'compilation-info'?
has caused the debbugs.gnu.org bug report #66041,
regarding 30.0.50; Should 'flymake-note-echo' inherit from 'compilation-info'?
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
66041: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66041
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
X-Debbugs-Cc: joaotavora <at> gmail.com
The faces 'flymake-error-echo' and 'flymake-warning-echo' inherit from
'compilation-error' and 'compilation-warning', respectively. However,
'flymake-note-echo' (and 'flymake-note-echo-at-eol') inherit from
'flymake-note'.
This results in some odd visuals in "emacs -Q" (and any theme that uses
similar styling): Flymake errors and warnings in the mode-line (or the
minibuffer/end-of-line) are red or orange text. However, Flymake notes
are the default text color with a green wavey underline. Especially when
they're side-by-side in the mode-line, the current visuals are
surprising (not to mention hard to see in the default theme).
Personally, I think it'd be better for the "echo" faces for Flymake
notes to just inherit from 'compilation-info'. They have almost
identical uses as far as I can tell, and then things would look more
consistent/readable. (In fact, we could even rename flymake-note to
flymake-info, but maybe that ship has sailed.)
[Message part 3 (message/rfc822, inline)]
On Mon, Sep 18, 2023 at 7:49 PM João Távora <joaotavora <at> gmail.com> wrote:
> That's possible to implement.
>
> But the single/multiple overlay decision is just an implementation detail
> Currently Flymake uses one "end of line" overlay only, but here the logic
> o control that uniqueness failed, so an extra unintended overlay was
> created, and that created problems with cursor placement.
>
> But your suggestion is noted, though.
Over the last 2 days, I've been working on this bug and pushed your patch.
I also significantly reworked and robustified the end-of-line overlay logic,
fixing the two bugs I had identified.
Then I also implemented your "and N more" suffix suggestion. Just set
flymake-show-diagnostic-at-end-of-line to 'short'.
I'm closing this bug, but let me know if you are satisfied with the changes
or notice more points of possible improvement.
João
This bug report was last modified 1 year and 296 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.