deadfoxygrandpa / Elm.tmLanguage

Elm language syntax highlighting and tool integration for ST2/3
https://packagecontrol.io/packages/Elm%20Language%20Support
MIT License
122 stars 27 forks source link

Request: no special highlighting for core functions #13

Closed evancz closed 9 years ago

evancz commented 9 years ago

(This is based on a recent mailing list thread)

Currently Dict.get and Automaton.run are highlighted different, which feels really odd. Both are functions from packages that someone else wrote. I personally feel that there should be no special cases when syntax highlighting variables.

I partly feel this way because my experience has been that there are tons of false positives. Things that I have defined are getting "special" highlighting because there's some function somewhere that has the same name. Things get out of date depending on what version of Elm you are messing with. And overall, I don't feel like I'm trading those problems for anything, things just are kind of weird sometimes.

I'd vote for "all variable names are highlighted the same" and "all infix operators are highlighted the same". It's easier to maintain and I think it's a better user experience.

Does this sound plausible or desirable to you?

evancz commented 9 years ago

I have some ideas about how to make the compiler spit out fully qualified names for all tokens, meaning "jump to definition" and "jump to docs" would be really easy. I think that's a way better route than visually distinguishing stuff that happens to be in elm-lang/core. It'd also apply to all packages equally.

So my vote is to plan for this route instead.

deadfoxygrandpa commented 9 years ago

Yeah, I agree with this reasoning. There's also a couple built in data types like Int and Float that I think are getting highlighted differently, and it's sort of bugged me but I haven't gone through to fix it yet.

evancz commented 9 years ago

Cool :) It's sort of strange that this is the default in so many highlighters. It was in the online editor for quite a long time as well. At some point I got tired of maintaining it and then was pretty happy with the result. Perhaps this seems more appropriate in other kinds of languages?

In any case, glad we agree :)

deadfoxygrandpa commented 9 years ago

Well, I wrote a script that takes docs.json and spits all this stuff out so it's pretty low effort to maintain, which is why I still have it in, really. I'm not very attached to the idea though.

deadfoxygrandpa commented 9 years ago

What do you think about special highlighting for types built in to the compiler, like Bool and Int? I'm leaning toward not giving these a special color different than any other type.

evancz commented 9 years ago

I also prefer that they have no special color. It feels weird to me when the types in Int -> Person are different colors. I think the built-in-ness is a implementation detail.

deadfoxygrandpa commented 9 years ago

I've made this change in the 0.14 branch, which I'll merge in with master when Elm 0.14 is released

deadfoxygrandpa commented 9 years ago

I just pushed these changes to the master branch.