go-mode does not correctly highlight Go types about go-mode.el

[dominikh]

This is to be expected. In a var statement, no types will be fontified; whether it be int32 or T. Doing so would require actually parsing the code, instead of relying on simple regular expressions.

The same can be seen for function definitions, although for that, there's https://codereview.appspot.com/81240047 – maybe the author of that will one day support var as well, if that's as easily to parse.

We can't simply fontify all built-in types, because they're not reserved words. Someone could do func int32() {} and that'd be legal code and int32 would no longer be a type. Also it would appear weird if only a subset of types got fontified correctly.

I'll leave this issue open and consider it a feature request. I wouldn't expect it to be fixed in the near future though.

[MatejLach]

Makes sense.
Thanks for the explanation.

[mpolden]

Maybe highlighting builtin types could be optional (controlled with a variable)?

[norbertklar]

I have this problem too. Please fix it(this issue still open after one year)!

Just a thought: Maybe you can simply write a filter, adding type names to it.

[dominikh]

Naively highlighting type names is error-prone, because it depends on the context whether an identifier is a type or not.

This really isn't an issue I am intending to fix any time soon. The only correct solution would require using a proper parser, and the complexity of that far outweighs the benefits.

[norbertklar]

In vim-go mode, they did a good job, they're just simple parsing for keywords without checking the context: maybe you should just add this feature - as an optional setting(Tho I don't know a man, who using a type name as a function name:D that just silly, misleading and bad practice).

[dominikh]

How does vim-go render the following piece of code?

package main

func main() {
  int := "hello"
  println(int)
}

Also, how does vim-go render the following?

package main

func bar(int) int { return 2 }

func main() {
    type foo int
    x := foo(1)
    y := bar(1)
    println(x, y)
}

[norbertklar]

[dominikh]

So vim-go gets both of them wrong, in exactly the ways that make me not implement it that way.

The first example is harmful, because the syntax highlighting is now wrong and misguiding, potentially hiding errors (you shouldn't be shadowing a built-in type name, because it's bad style, but the bugs it leads to are harder to diagnose if the syntax highlighting is wrong, too).

The second example is harmful because it means that syntax highlighting is only reliable for a subset of types, which also makes it a lot less useful.

(Note to others reading: The second screenshot and my second code snippet show different code. I edited mine after first posting it, my fault. But they show roughly the same issue.)

If you really want such simplistic syntax highlighting for types, you can easily add that yourself, by extending go-mode's fontification table. I won't make it part of go-mode, however.

[norbertklar]

I understand the issue, but why hard a such a thing to implement in emacs(I don't know too much about emacs-lisp)?

[dominikh]

Using vim-go's way would be incredibly easy. Doing it the proper way would require writing a parser for Go code in emacs (although CEDET might help there), which is about as complex as writing a parser in languages other than elisp. However, it would add additional complexity because we'd have to implement fontification ourself, and it would have performance implications (we'd need to parse the buffer every time we'd need to fontify it again).

[AeroNotix]

And I believe this go-mode.el was made specifically because the older one tried to implement a parser.

[dominikh]

Sort of. The original go-mode had a bastardized version of a "parser" to implement indentation and basic syntax highlighting, but it wasn't working any better (in fact, worse) than Emacs's built-in facilities. It was nowhere close to solving this issue.