Syntax Highlighting for core types

[rtfeldman]

I’ve noticed that it’s common in Elm syntax highlighters to make a visual distinction between types in core - for example String, Int, and Bool - and all other types.

I think it would be an improvement to highlight all types the same way. If I write these two functions:

foo : String -> User -> Thing

bar : Something -> User -> Thing

…I think it’d be nicer to have both functions highlighted the same way than to have only String highlighted differently from the others.

I’d like to spread this idea around to editor plugin authors, but first I’m looking for feedback.

What do others think of this idea?

[MorganEarlJones]

I’d go a step further and highlight [non-core] types/functions with different tones depending on whether they’re defined in-file, locally, or in an imported package.

[bennett]

I support this. I think there are other interesting/useful possibilities for communicating via color, but I don’t think “built-in” is particularly meaningful.

I’d be interested in seeing differences based on container vs terminal types. So List Int would have different colors for List and Int. Could be extended to higher-kinded types if those ever show up.

[rtfeldman]

Whoa, hi @bennett!

Did not know you were on here!

[bennett]

Just joined. I’ve been using Elm for some personal projects recently. LMK if you’re ever in NYC.

[kevinyank]

I have no strong opinion on this and am happy to adapt (or accept a PR adapting) the Sublime Text package, which I maintain, according to community consensus.

I will say that as a newbie learning Elm, being able to see what was coming from surrounding code or dependencies and what was “core” was really helpful. My (loosely held) preference would be for all implicit imports (including, for example, toString) to be coloured differently.

[tibastral]

I think you are totally right, making this distinction doesn’t make any sense.

[Collin]

I think colored Like a type but a slightly different hue would be perfect. sometimes you look at a new elm project and see:

foo : String -> User -> Thing

bar : Something -> User -> Thing

And it would be nice to have a visual clue that “Something” is actually a type defined somewhere here or possibly just an alias, and not possibly a function being passed to bar. Which… I know is technically a “kind” of type in itself, but for Elm purposes, I see what Richard is getting at.

[mfeineis]

Just be sure to think about accessiblity, some 8% of male humans have trouble telling red and green apart, so it’s a good idea having enough contrast between the different hues

[z5h]

I think it would be an improvement for how I personally prefer to look at code. But I don’t see how one can claim that it’s an improvement for everyone and their way of coding.

Personally for me, I find too many syntax colours distracting. I can’t focus on my work. I have 3 syntax colours: code, comments, strings. I think it would be an improvement for all editors to work this way out of the box and not support any other schemas. But I’m not sure that it’s best for everyone.

Why do you think your suggestion would be an improvement for everyone?

[Tomas_Metz]

Looks like an extension to an idea of semantic highlighting: https://medium.com/@evnbr/coding-in-color-3a6db2743a1e

I’d appreciate to differentiate between Dragon and Maybe Dragon.

I was using this semantic highlighting, when coding in JS and it was worth it.

[Duncan]

Talking in general terms, tasteful syntax colouring abides by the concept of

“Just because you can, doesn’t mean you should.”

i.e. Colour a handful of token kinds that warrant it. Don’t go overkill and try to comprehensively colour every kind of token in the language!

A great example of this is symbols like = and [ and + and so on. They inherently stand out purely from the shape of their glyph! Why are they often given some punchy colour, and not simply the default foreground colour of the view (black-ish / white-ish)?