GNU bug report logs - #40351
Flymake error count

Previous Next

Package: emacs;

Reported by: sir <at> hacktivista.com

Date: Tue, 31 Mar 2020 15:37:02 UTC

Severity: normal

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#40351: closed (Flymake error count)
Date: Mon, 12 Dec 2022 08:51:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Mon, 12 Dec 2022 00:50:42 -0800
with message-id <CADwFkmkohw6EB2_YSXX=6B3=4T9WrPsSAbkBAbLqvwAnofuXBw <at> mail.gmail.com>
and subject line Re: bug#40351: Flymake error count
has caused the debbugs.gnu.org bug report #40351,
regarding Flymake error count
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
40351: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40351
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: sir <at> hacktivista.com
To: bug-gnu-emacs <at> gnu.org
Subject: Flymake error count
Date: Tue, 31 Mar 2020 07:21:54 -0300
[Message part 3 (text/plain, inline)]
I've created a flymake backend based on the flymake docs: https://www.gnu.org/software/emacs/manual/html_node/flymake/An-annotated-example-backend.html#An-annotated-example-backend

It works, but I'm also using Eglot, and noticed that on the error count displayed on the status line of emacs it doesn't count properly for my backend. It displays a number 1 for each error it discovers, but Eglot errors are able to increase the number of its backend. This is what displays my status line:

(PHP//l company Flymake[1 1 1 3 0] ...)

It should display ... Flymake [3 3 0] ...

The attached image will explain it better. I'm attaching the backend also, if you need to see the code (though it's actually pretty much the same as the example in docs).

How could I make my backend increase the error count instead of creating other counter?

[eglot-flymake.png (image/png, attachment)]
[flymake-phpcs.el (text/plain, attachment)]
[Message part 6 (message/rfc822, inline)]
From: Stefan Kangas <stefankangas <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: sir <at> hacktivista.com, 40351-done <at> debbugs.gnu.org
Subject: Re: bug#40351: Flymake error count
Date: Mon, 12 Dec 2022 00:50:42 -0800
João Távora <joaotavora <at> gmail.com> writes:

> Hello, sir <at> hacktivista.com:
>
> I'm sorry for the very long delay in answering this.  Next time you
> report a bug for flymake, make sure you also forward me the message that
> the bug reporting system sends back to you.  (yes I know you had written
> me separately).
>
> Anyway, to your problem:
>
>
>>                        for (beg . end) = (flymake-diag-region source lnum)
>>                        for type = (make-symbol (match-string 3))
>                                      ^^^^^^^^^^^
>
> I think the problem you experience is found here.  TYPE cannot be a
> different symbol for each error you find, otherwise Flymake will think
> that each error has its unique type.  If `(match-string 3)` is indeed
> often enough the same string, you can try `intern` instead.
>
> Let's say (match-string 3) can only return "oops", "warn" or "info" I would write
> that line like
>
>     for type = (intern (format "flymake-phpcs--%s" (match-string 3)))
>
> Then separately I would write in a top-level-form
>
>     (put 'flymake-phpcs--oops 'flymake-category 'flymake-error)
>     (put 'flymake-phpcs--warn 'flymake-category 'flymake-warning)
>     (put 'flymake-phpcs--info 'flymake-category 'flymake-note)
>
> Then the errors would be merged with the errors from Eglot, I think.
>
> See the manual section 2.1 Customizing Flymake error types
>
> I see the the docstring for `flymake-make-diagnostic` could see some
> improvement.  In particular, the phrase "TYPE is a key to symbol"
> doesnt' make much sense.

There have been no further replies here within 2.5 years, so I'm going
to assume the above was enough to resolve this issue.  I'm therefore
closing this bug report.

If this conclusion is incorrect and this is still an issue, please reply
to this email (use "Reply to all" in your email client) and we can
reopen the bug report.


This bug report was last modified 2 years and 166 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.