Add support for highlighting function calls

[svanharmelen]

g:go_highlight_methods highlights method calls, but g:go_highlight_functions does not highlight function calls.

So this PR adds the same highlighting for function calls as well. See the examples below where the call to demoFunc() is not highlighted initially where the call to demoMethod() is.

Before:

After:

[fatih]

Hi @svanharmelen

This looks like a nice idea, however this is not suitable because you also use it to create variables of custom types:

As you see, here MyString() is not a function, but it's also highlighted. This is not something we want to merge because we don't have the AST information. You can do a back and forward research and match and check it if it's a type declaration or a function declaration, but that would only increase it.

I'm closing this, feel free to reopen if you think this can be fixed in a simple way.

[svanharmelen]

Hmm... In a way I understand what you're saying, but if I look at some other popular editors out there...

Sublime:

Atom:

It looks like they do highlight this. So that makes it feel a bit strange that vim does not (IMHO)...

[fatih]

It seems, they both are handling it incorrectly. I think they should fixe those or not highlight at all :)

[svanharmelen]

@fatih I would like to ask you to reconsider your take on this one... I fully understand your point of view, but for the sake of consistency I still think this PR makes sense.

Take for example this piece of code from Kubernetes (see here):

So here NodeName is highlighted as a method/function, but in fact it's a type (see here):

So that means this is highlighted in all cases, except for when you convert a type to a type that is declared in the same package. In all other cases it will be highlighted.

So I would like to ask if you can think about this one last time 😉

[svanharmelen]

@fatih any thoughts about the last comment I made?

Again, I do understand your point of view and purely technical you a 100% right. But for consistency sake (both consistency between editors and consistency within vim itself (e.g. the local package vs other package type cast example) I still think this PR makes things better.

Another way to look at it is to say it's wrong either way. We now wrongly don't highlight local functions. This PR fixes that, but now converting types with locally defined types is highlighted wrongly.

Looking (at least at my own code and the projects I work in), the number of times I use a local function is way, way more then the number of times I convert a type with another locally defined type. So (IMO) merging this PR would reduce the number of incorrect highlights and so would be an improvement right?

But again, consistency is a big thing for me and I do believe this PR increases the consistency. So please let me know you thoughts and if we could reopen this PR. Thx!

[fatih]

@svanharmelen thanks for your comments on trying to convince me. I've decided to merge it because of two points. First I think you're right on your comment that fixes one of the things that is more in common (function calls), second because this is behind a flag, it's already totally optional.

[svanharmelen]

Whoohoo 🎉 Thanks Fatih 😀