Fixed highlighting of brackets, punctuations and identifiers.

[Victorystick]

These changes make sure that:

• map and chan are highlighted as keywords.
• Brackets are no longer highlighted as keywords nor operators.
• ; is no longer an operator
• package name is no longer highlighted as a variable
• regular variables are plain source

Addresses issues #32 and #35. All in all, it's much easier on the eyes. Before:

After:

[joefitzgerald]

/cc @svanharmelen

[svanharmelen]

Even through your absolutely correct that both chan and map are listed as reserved (key)words, they are also both types (https://golang.org/ref/spec#Map_types and https://golang.org/ref/spec#Channel_types) listed and explained right along side all other types (https://golang.org/ref/spec#Types).

Taking that into account and looking at how the words are used within the language (to define types) I think it makes much more sense to assign the storage.type.go scope instead of the keyword.go scope.

[Victorystick]

It is true that chan and map are keywords used to define types; your opinion isn't unfounded.

However, the specification does list them as keywords. Additionally, all other type related keywords type, struct, interface and func are arguably also used to define types, but they aren't marked with the storage.type.go scope; they have the keyword.go scope. So should chan and map.

Consider this example using all type related keywords:

type oddMap map[*func(interface{}) int]<-chan struct{}

[svanharmelen]

If you look it this with the theme I'm using, the current scoping still makes a lot more sense to me:

It makes very clear that I'm using the types map and chan. If you make them as keywords they fade away together with all the other keywords making the same line harder and less clear to read:

So IMO this should really be scoped as storage.type.go.

@joefitzgerald what's your take on this specific one? It seems the language spec leaves room for both keyword.go and storage.type.go to be used. So it comes down to usability and personal preference I think...

[Victorystick]

It's a bit of a silly example, of course. It's very unlikely to use all type related keywords together like that.

The difference with the new scopes on a more likely example is more appealing:

and

Builtin functions, keywords, primitive types and other types, are all highlighted differently.

[svanharmelen]

@Victorystick thanks for the PR and sorry for having so much comments... I do however think all my comments are valid and that (overall) this PR doesn't improve this package.

The purpose of this package is to "understand" as much as possible of the Go language in order to scope all parts of it correctly. The more parts it can scope correctly, the better any Atom theme can use those scopes to create good highlighting.

So it seems a little that what you are trying to solve (make the highlighting easier for the eyes) should be solved/changed in the theme package you use and not in the language package. For example the Monokai theme I'm using (https://github.com/kevinsawicki/monokai) works very well for Go and seems very relaxed for the eyes while it uses this same language package:

[Victorystick]

I whole-heartedly agree that the scoping should be as accurate as possible. That's why I decided to contribute.

The second paragraph of TextMate's Naming Conventions you linked me (which is great, by the way) says:

There are however conventions so that one theme can target as many languages as possible, without having dozens of rules specific to each language and also so that functionality (mainly preferences) can be re-used across languages, e.g. you probably do not want an apostrophe to be auto-paired when inserted in strings and comments, regardless of the language you are in, so it makes sense to only set this up once.

Some syntax themes in Atom highlight keywords and operators in very distinctive colors, see the Before image. Meta characters aren't highlighted, since they are more or less noise. (We might need braces and semicolons to disambiguate the language grammar, but they don't really add meaning to the program. Go could have used indentation instead of braces, although I prefer their choice on the matter.) If all this noise is given strong colors, which detract from what's important. I've considered using a different theme to subvert the problem, but that just doesn't align with the goals TextMate laid out with their naming conventions.

I believe that Atom's various syntaxes (which work great across such a wide range of languages) should all work equally well for Go.

[svanharmelen]

@Victorystick so I think we are pretty much aligned now right? Except for chan and map I think we are pretty much on the same track.

So could you update the PR to reflect the things we discussed?

[svanharmelen]

@Victorystick only one thing left... You still need to delete the semicolon from the operator list (was previously on line 162) as it's now beging processed twice.

After that I think we should be ok to merge this one. I had another few thoughts about chan and map and purely based on the specs maybe we should just go along with the change your purposing 😉

So if you could just remove the double semicolon, that would be great.

[Victorystick]

Absolutely. I'll get it done within an hour or two. I've really enjoyed your quick and direct feedback. 😄

[svanharmelen]

Sorry but my eye just caught a small thingy in the regexp you added later for the package name... Please see the inline comment.

[svanharmelen]

Just noticed the ? at the end of the regexp and I understand why you added it, but wonder if it's the best way...

Wouldn't it be better to revert this so package is matched together with import again (like it was before) and then add a regexp like this: 'match': '\\bpackage\\b\\s+([\\w_][\\w\\d_]*)'

This way package will always be scoped correctly, and independent from that word, the package name will also be scoped correctly. It seems this would be a little more robust while having the exact same result.

[Victorystick]

Yes, you're right. I'll do so today.

[svanharmelen]

LGMT! Thanks again for your efforts!

[joefitzgerald]

👏 thanks for the great work guys!

[joefitzgerald]