Add additional symbol kinds for current_function - #49
Conversation
There's little reason not to want to display enums, structs, and interfaces. They tend to be top-level in languages which define them, so they aren't competing with anything, like some of the smaller symbol kinds are. The updated formatting of the conditions is to keep the line length low.
These are also generally top-level, and (based on admittedly limited testing) don't interfere with other kinds.
This will help people set `kind_labels` by giving them an exhaustive list of kinds they need to set labels for.
wbthomason
left a comment
There was a problem hiding this comment.
Thanks, this looks good! I have one naming request for consideration, and one requested style change, but otherwise I think this is good to go.
As suggested by the initial PR review, this significantly improves readability and maintainability.
Not sure why I thought table keys could be strings.
(Why you don't commit to a PR branch even for minor things.)
|
Is it possible to use built-in |
|
@Shatur95 Won't that cause issues if users customize Also, right now, this is nothing extra to configure. Are you referring to customizing how the current symbol is displayed, or filtering the set of symbol kinds to display? |
No, this plugins just sets
I was referring to the display settings. I need to set |
|
Ah - I think this is actually a different issue, that of unifying |
|
(+1 to using |
|
Yes, I just asked, sorry for confusing :) |
|
I think this is good to go. Thanks, @nihilistkitten! |
Resolves #48.
This is a larger list of symbol kinds than the original issue, but I think it's justified. These kinds all tend to be top-level, which means you wouldn't lose other information by including these.