Don't count info messages as warnings

[mphe]

ALE differentiates between info, warning, and error. Infos should not be listed as warnings.

[maximbaz]

Thanks!

I haven't used this plugin for a while, but I'm reasonably sure that infos were considered as warnings on purpose, and the naming was unfortunate, it should have been named "non-errors".

With your change, if you have no errors or warnings but only infos, this plugin will neither show error / warning count nor OK segment, right?

Maybe a proper solution is to add yet another segment for infos, and then have three segments (error, warning, info) instead of the current two (error and non-error), what do you think?

[mphe]

With your change, if you have no errors or warnings but only infos, this plugin will neither show error / warning count nor OK segment, right?

You're right. It should at least show OK. Haven't noticed that yet, since I removed the OK segment from my config.

Maybe a proper solution is to add yet another segment for infos, and then have three segments (error, warning, info) instead of the current two (error and non-error), what do you think?

Either that, or maybe another variable the user can set to determine whether or not to treat infos as warnings. On the other hand, ALE provides g:ale_type_map to redefine message types, so a new separator for infos would probably the best. I'll look into it, should be rather easy to implement.

[mphe]

Alright, finally found some time to do this. Added a separate segment for infos, added respective variables, and updated the readme.

[mphe]

The problem with left is that it changes color depending on what mode you are in, and has usually bold text, which is rather undesirable for the info count imo. Since it worked for me with just normal, I assumed it is defined as some default, but apparently I was wrong. Looking at the docs again, unfortunetly lightline is not clear about what happens if you specify a color region that is not in the colorscheme. I did some testing, and apparently it uses the first color defined in normal.right (basically the last value in the flattened normal colors list). So this should be correct, or at least better than left. But I agree, this should at least be changed to right. Another question is, should the other styles (ok and checking) be changed to right, too?

[maximbaz]

I don't think "left" was bold on my colorscheme... But in any case, I'm up for consistency, and given than people seemed to be generally happy with the defaults so far, let's perhaps not make changes in this PR, make the new section also "left" and if you want open a separate issue for changing defaults to "right" and see if others feel the same?

[mphe]

I don't mind the linter status labels being left, since it's a status indicator similar to the mode indicator. However, the info, warning, and error counter, is not really a status, therefore I think none of them should change colors when changing modes. Also just looked at lightline's colorschemes. Most of the time right seems to be the same color as left but without changing colors depending on which mode is active. Hence I think right would fit better for the info section.

[maximbaz]

To clarify, do "warning" and "error" change color based on the mode like "left" does? Sorry I'm a bit out of context, what exactly are the modes, insert and normal?

[mphe]

Yes, I mean vim modes (insert, normal, visual). If you look here at this colorscheme, for example, you can see the color definitions for normal, visual, and insert. For each mode there's a separate definition of left with different colors. Other stuff like warning, error, or right is only defined once for normal, meaning it will use the same color independent of current vim mode.

[maximbaz]

OK, I accept your argument, let's go for "right" 👍 Will you replace other occurrences where we currently use "left" to be "right"?

[mphe]

Done :+1:

[maximbaz]

Thank you for your contribution and all the investigations, enjoy!