GNU bug report logs - #33740
[PATCH] Customizable flymake mode-line indicator

Previous Next

Full log

Message #41 received at 33740 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 33740 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#33740: [PATCH] Customizable flymake mode-line indicator
Date: Wed, 18 Sep 2019 14:59:08 +0100

[Message part 1 (text/plain, inline)]

On Wed, Sep 18, 2019 at 2:40 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> João Távora <joaotavora <at> gmail.com> writes:
>
> > Thanks, Lars.  I'm away from my emacs dev machine so I can't read the
> > diff very carefully, but if you want to risk it, go ahead and push,
> > because I like the defcustom spec and I see you've kept the default. A
> > short entry in NEWS and the Flymake manual is probably worth it (but
> > you can skip the latter).
>
> Well, it doesn't quite work yet, so it's a bit premature.  :-)
>

I see, what's wrong with it?


> > There are arbitrary errors levels in this flymake (not just error
> warning
> > and note). But those are the main ones and anyway we can always
> > add more format machinery later.
>
> Hm, is there a list of all the error levels?  If not, I think the
> approach I took in the patch is probably misguided (what with %e for
> "error" and stuff).
>

There isn't a list of error levels, there are just severities. There are
some built-in flymake _categories_ linked to the symbols :error, :warning
and
:note that connect these symbols with some preset severity.

But flymake can work with annotations of arbitrary severities with some
user-specified meaning. Hence errors, warnings, notes etc are just
annotations of severities 3, 2, 1, respectively. This was tied to
warning-numeric-level, which predates flymake.

So I see "%e" as a shortcut for, say, "%3a" (number of annotations
of severity 3), which is no problem imo. "%na" is the thing that could
be implemented later...


> > I see a lot of changed lines, but most of them are probably whitespace.
>
> Yes, it's mostly whitespace due to rearranging the way the strings are
> computed.
>
> > Is there some diff format which elides those?
>
> I'm not sure?
>

I think git diff -w does something to that effect.

João Távora

[Message part 2 (text/html, inline)]

Previous Next

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