-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Highlighting arguments #1587
Highlighting arguments #1587
Conversation
Seems to work well in a quick test. Thank you! The only thing that doesn't seem to work is return values for methods: I would expect I think it would be better to add a new option for this, for example If you hide it behind a flag we could also highlight it by default. Maybe |
Thank you. Yep, I agree with all these issues. I'll implement them soon. |
Done. Only I named option |
syntax/go.vim
Outdated
@@ -350,12 +354,15 @@ if g:go_highlight_functions != 0 | |||
syn match goPointerOperator /\*/ nextgroup=goReceiverType contained skipwhite skipnl | |||
syn match goFunction /\w\+/ nextgroup=goSimpleArguments contained skipwhite skipnl | |||
syn match goReceiverType /\w\+/ contained | |||
syn match goSimpleArguments /(\(\w\|\_s\|[*\.\[\],\{\}<>-]\)\+)/ contained contains=goArgumentName nextgroup=goSimpleArguments skipwhite skipnl | |||
if g:go_highlight_function_arguments != 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't look too deeply yet, but would it be possible to move this out of the if g:go_highlight_functions != 0
block? Then people can set these two settings independently.
If this isn't possible then that's not a disaster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to parse "func", probably receiver, and function name before trying to highlight arguments. So it is possible but we will need to copy half of just function rules. So I put these new rules inside.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However it may be worth to enable g:go_highlight_functions
if this new setting is enabled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did it and pushed. Otherwise users can spend their time figuring out why it doesn't work although setting is set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However it may be worth to enable g:go_highlight_functions if this new setting is enabled?
Sounds good 👍
1de3f47
to
545a645
Compare
Works well in my testing. Thanks! |
I prefer to highlight function argument names to be able to distinguish them from their types.
This pull request:
It deliberately doesn't work for nested functions. It can be a case when a function is an argument type or it is inside function declaration (it can be a field of anonymous struct for example). Unfortunately I didn't find a way to support it without big rewrite of syntax rules. So it is checked if declaration contains inner parentheses and this highlighting is turned off if so.
Before:
After:
It relates to this pull request #1580 that I closed because it doesn't work well with nested functions. This one has additional fixes as well.