Configuration for diagnostic icons

[smbroadley]

This is to aid accessibility.

Some themes are not great for colourblind people. With this configuration, they can easily change the icons that appear around the editor (gutter, status bar) to make them easier to distinguish!

[nik-rev]

thanks, this is fantastic!! #1 rule in design is to not rely on color (well, there are a lot of #1 rules but this is one of them) :)

[the-mikedavis]

I'd like to see the defaults changed rather than introducing more config especially if it's for accessibility - we should shoot to have something that reads well out of the box. Instead of reusing the same circle glyph for all diagnostic levels we should be able to find different simple glyphs. Maybe a triangle for warnings, square for errors, circle for hints.

[smbroadley]

Interestingly, those glyphs are what I have set my custom cut to. 😄

[koolfy]

We could progressively more eye-catching glyphs as we move from "INFO" to "ERROR", so that even with a dense file with lots of LSP information, one might be expected to visually find the important ones and ignore the noise.

• HINT: ⋅
• INFO: ○
• WARNING: ●
• ERROR: ✕

edit: I edited down my obnoxiously long comment because omg I am bad at getting to the point

[smbroadley]

You shouldn't have edited your message! It was heartfelt and important. It is only when we hear about a product experience that we can start to find a way to improve it.

I have been taught many a time that my designs do not work for everyone; AND while making something for everyone is hard, it is seldom impossible.

We have maintainer alignment, and we will have improved the experience for everyone! Go team!!

[nik-rev]

Having complex symbols can add clutter and I really like what the-mikedavis suggested, so here's my take on it:

• circle for info ●
• triangle for hints ▲
• square for warnings ■
• pentagon for errors ⬟

I really like this approach because there's a clear design here. The sharper the symbol, the more severe it is:

• Info has 1 side
• Hints have 3 corners
• Warnings have 4 corners
• Errors have 5 corners

Usually sharp and pointy things are associated with danger. So having it be on levels like that sounds like an idea to think about

[nik-rev]

Imo it's important that the design is consistent. We can't just have one icon try to convey meaning and another is an abstract shape. Or one is filled and the other one isn't.

[smbroadley]

Thankfully, I have a build where I can easily change them at runtime, and sit with those choices for a bit. I would love it for you to do the same and see if you still feel like those work! (I will!)

[smbroadley]

One additional wrinkle for this that I'm not sure of is which glyphs are we leaning towards that we expect will render consistently across platforms!

[the-mikedavis]

I don't have strong feelings about most of the glyphs but I would prefer triangle for warnings since it looks like a simpler '⚠️' (https://emojipedia.org/warning).

Similarly I think a square works nicely for error because of similarity to '⏹️' (https://emojipedia.org/stop-button).

I'll try these for a while and see what I think but I am running with:

• error: ■
• warning: ▲
• info: ●
• hint: ○

locally.

Info severity doesn't seem to be used often so I think it's ok that info and hint are somewhat harder to distinguish than the others.

I'd like to keep these glyphs as simple as possible since monospace fonts can be a bit unpredictable - more complicated symbols like https://symbl.cc/en/2297/ can look quite busy on some fonts. And anything with more than 4 sides can be hard to recognize at a glance IMO.

[smbroadley]

There is one other thing that irks me: currently in the status line we render warnings, then errors. For some reason my brain hurts seeing it that way. (Hello arbitrary bias!) 😆

[koolfy]

@nikitarevenco I like the logic of more pointy = more priority intellectually, but I realized the flaw when I found myself squinting and getting my face closer to the screen to notice the difference between the info circle an the error pentagon (coincidentally the worst possible confusion of opposite priority levels)

It may be because of my dark mode, my browser font or like @smbroadley suggests how my system renders these glyphs

Also a file rich in these indication (that ugly code it fell on you to refactor ahem ahem) might initially be a shapes-soup, where info is as visually-heavy as warnings and hints look like high-priority/danger road signs

Before landing on the very distinct cross, I was going to suggest a triangle for "ERROR" for this exact reason, in all cultures the triangle is the ultimate priority because the roadsign conventions are universal and commonplace

The "more corners" rule might be confusing in a file with only hints and warnings: without context one might reasonably assume most attention should be payed to the "caution triangle" than to the "square whatever" and

1. not realize the triangle is not an error and can be safely ignored
2. exactly invert the priorities of INFO and WARNING

I also find that in hidpi environments with large screens that might not be that close to the eyes, small similarly-sized shapes might become harder to distinguish. A solid square and a solid circle can look alike in these situations.

The smallest ⋅ can never be mistaken with another symbol, the ○ is the only hollow shape (and that's easy to distinguish in any font and any size) , the solid ● is effectively the only "solid" shape and the ✕ is both un-ambiguous in its meaning and so far from all other shapes that no confusion is possible no matter the font, size distance or visual acuity

I have 20/20 vision but only this proposal can still be worked out standing very far away or squinting, without relying ot making the glyphs bigger and more visually distracting (it also works if you don't realize/pay attention to the "more corners" logical rule)

However, the original intent behind this PR is to adress color-blindness, and for that any shape would do :) so I won't argue further If it remains configurable on top of better defaults, I can live with setting these glyphs I like on my config file.

[smbroadley]

I'm currently rocking:

[editor.diagnostic-icons]
error = 'x'
warning = '▴'
info = '•'
hint = '•'

and

[editor.diagnostic-icons]
error = '!'
warning = '▲'
info = '•'
hint = '•'

[smbroadley]

Also:, this isn't terrible:

[editor.diagnostic-icons]
error = '≡'
warning = '▴'
info = '•'
hint = '•'

[koolfy]

I've been using the glyphs I suggested for a day (got tunnelled into my work and forgot to switch them around), but I only encountered hints and errors, no warnings or info!

I noticed the ⋅ for hints really works well to de-clutter with un-obtrusive icons for such low priority diagnostics. Often I noticed underlined text first, and only then did I look for the diagnostic icon to see it was a hint, it never distracted me away from the code right away (because it's so small and stealthy)

Errors with the ✕ worked very very well, I had zero doubt about what they were, no hesitation and they always stood out.

I think it might make sense to have the same symbol for hints and info levels, as they are both almost equally "less-relevant", whatever we land on I would agree that the first priority for hint and info is to be "non-distracting"

The problem I have with mixing triangles, "!", crosses etc for warnings and errors, is that it will never be immediately clear which one is the "clearly broken" one. If we set warnings to triangles and errors to an exclamation mark, and when you open the code you see either, they both look severe enough that they might be errors.

I think the warning glyph should be visually noticeable but avoid any "threatening" symbolism. Exclamation marks, crosses, triangles and anything culturally associated with danger should be reserved to actual errors

For example:

[editor.diagnostic-icons]
error = '✕'
warning = '●'
info = '⋅'
hint = '⋅'

works very very well for me and allows zero confusion in any direction (as long as we consider it's okay to conflate hints and infos. If it remains configurable., someone who really cares about hints vs info day-to-day might be okay overriding it. To me it feels like an uncommon enough usecase.)

Any of the ▲ ! or ✕ would work equally for errors I would say. Maybe "!" a bit less so as the glyph being aligned to the left of the window a slim vertical shape might not be spaced enough from the window border to stand out, but I'm nitpicking.

My only gripe with ≡ is that it misses any of the visual clues commonly associated with danger/warning signs, so a new user might think this is the hint/info/warning "less-threatening" symbol and would need to mentally learn this symbol.

But again, this is just feedback, at this point a distinctive glyphset solves the initial issue raised and I'm perfectly happy overriding sane default with my preferred symbols, so this opinion should not stand in the way of merging another proposal ;)

[koolfy]

As a testimony, I've been using the icon-set described in my last comment for about two months now for work (daily with varying intensity depending on workload type), and it's been working like a dream for me

• I have never again felt like I missed some information because of color coding (as I intuitively never had to rely on it as much)
• I have never had a single doubt on the priority level of an icon I saw and its meaning
• I have correctly been able to visually ignore hints while noticing them when I looked for them
• I have correctly been able to not be alarmed by round ● "warning" icons when they appeared alone
• I have always noticed the ✕ "error" markers when they appeared

This setup is a success for me on all fronts, I recently remembered this was not helix's defaults as it very quickly became natural for me. I have not needed any adaptation period and didn't need to "train my brain" to associate each icon to its meaning, it worked right away (contrary to other previous attempts - even my own previous suggestions were less smooth)

This is of course a biased testimony as I'm using the set I suggested, so it's a given that it makes sense for me. It is inevitable that other people's brain are wired differently and might perceive it differently! However I think this proposal at least would not actively confuse people and would be easy to adopt.

I'd be interested to know if there is consensus on this proposal, and whether other people encountered enough friction to consider this proposal "not universal enough" to be made helix's defaults

[koolfy]

Hello, do we need anything else to get this merged?

From what I see the master has diverged enough now that conflicts need to be resolved, and some useful features merged in master would be very useful to me at work, so I might need to rebuild my helix and move away from this branch.

This MR and the icon set I was using made life significantly easier for me, on a daily basis.

Looking for this issue, I think I've found many similar (or competing?) issues/PRs, maybe this is a reason for this one to be held off? Maybe the aim is to implement a more general solution that goes beyond diagnostics icons?

Is this leads nowhere don't hesitate to state so and close this one, so we can focus/follow the effort at the tip of the spear ;)

Edit: just to re-state the intent behind this effort: as-is, leaving this branch will mean a significant accessibility regression to me, as a colorblind person. I will survive it but I'm very interested in following the progress of similar efforts

[the-mikedavis]

For configuration I'd prefer to have something comprehensive rather than adding a bunch of different config options piecemeal.

I'm still interested in changing the defaults though so not all diagnostics are ●. I've been running with https://github.com/the-mikedavis/helix/commit/d52a87f291325fc5734bc84511dbb056dad70094 for a while and I like having the different glyphs. I'll make a PR for that so we have a place to bikeshed on which glyphs to use.

(Edit: https://github.com/helix-editor/helix/pull/13736)

[RoloEdits]

From what I see the master has diverged enough now that conflicts need to be resolved, and some useful features merged in master would be very useful to me at work, so I might need to rebuild my helix and move away from this branch.

@koolfy If you are thinking of building from source anyways, you could cherrypick/use https://github.com/helix-editor/helix/pull/12369. I am trying to keep it as a single commit that can be easily moved around, and try to update as fast as possible to resolve any conflicts.

edit: I see #13736 changes the defaults, but if you still want different ones, you can use the icons PR. There are still design issues for it, but functionally it works as expected.