Symbol List definitions are affecting other languages
rahul-ramadas opened this issue · 15 comments
The Symbol List definitions of C Improved are not specific enough; they are interfering with the Symbol Lists of other languages as well. Instead of the scope string being something like entity.name.function.declaration, it should probably be something like source.c entity.name.function.declaration.
Thank you for reporting. It seems you right. But another problem is that C-family languages other than C itself provide different outermost scopes (like source.c++). Do you have any ideas how overcome this without making a copy of Symbol List files for each language?
You should be able to list them comma-separated like so: source.c entity.name.function.declaration, source.c++ entity.name.function.declaration
Reference: http://manual.macromates.com/en/scope_selectors#grouping
Yeah, I know about this feature, but it doesn't seem to me like the proper way of handling this. I mean that now C Improved is effectively unaware of any languages that extend it, that is there is no any mention about say C++ now.
Maybe one could introduce a common intermediate scope like meta.c-improved so that is would tag the whole file regardless the outermost scope. In other words, C sources would become source.c meta.c-improved, C++ - source.c++ meta.c-improved, etc. In this case this common scope could be used in Symbol Index files instead.
I'm not sure I follow. Does CImproved need to work with other languages?
Not exactly, but sort of. It defines the syntax of C, which is bound to source.c scope, which in turn is included in syntax definitions of C++ and Objective C. That is, whenever you change C Improved.tmLanguage file this also affects these derived languages as well.
I'm not sure how to precedence of different Symbol Index.tmPreferences work. It is possible that for a different language I may want to display a different kind of symbol index. For instance, for C++ I may want to show the namespaces as well. Looking at the default C++ and Objective-C packages, they have their own Symbol Index files, and they are specific to the language they are defining; source.c++ and source.objc. So if you define your Symbol Index the way you suggested, I'm not sure what the resultant behavior would be.
Yeah, you're right. It's definitely a subject to clarify.
BTW this page defines the precedence rules: http://manual.macromates.com/en/scope_selectors.html#ranking_matches
Since this (defining Symbols specific to the syntax) seems to be what most packages do, I think it should be okay for you to do the same as well. Even if some other C-family language is inheriting the C syntax, they will probably define their own Symbol Index anyways.
Ok, I don't mind implementing it as you proposed initially (through multiple Symbol Index files or multiple scopes in a single file). I have to allot some time to make this change though.
I can send you a PR. But just to clarify, the Symbol Index files for CImproved should match only source.c right? I just realized right now that CImproved by itself does not recognize C++, so there is no point in matching source.c++ as well, since it would just interfere with the Symbol Index file defined in the C++ package.
Hmm, yes, I suppose. However it is worth checking if Symbol Index builds properly for C++ after the change.
P.S. PRs are always appreciated. ;-)
Thank you, I've merged it. I'll tag a new version a bit later, so that this change would arrive to Package Control as well.
Sorry for being so lazy, but finally I've pushed pushed a new tag (v1.1). I appreciate your contribution!
I think the tag should be of the form a.b.c. It looks like package control does not pick it up otherwise.
Oops, fixed.