Variable declaration highlighting differences

[jibsen]

Inside functions, if a variable declaration contains more than one variable, the last one is variable.other.c, the others are not:

Personally, I think I would prefer none of them are highlighted, so they match the variable names in the function type and global scope.

[jibsen]

It just dawned on me, is this an issue with the default C++ package rather than yours?

[abusalimov]

Thanks for reporting this. I wouldn't notice it by myself because of using Monokai Soda, which highlights both variables from your example in the same way. The default C++ package doesn't seem to highlight them at all, though I can recall, there definitely was a regexp for variable initialization: it wasn't something that I've introduced and implemented from scratch, I could possibly fix it in some way, and it seems I missed some cases. It's pretty hard to parse C (which often has lots of macro-expanded stuff) using regexps, but I'd rather add a proper highlighting for parameter names (like I've done for #define macros). BTW how does your color scheme highlight macro parameters?

[jibsen]

The color scheme is Solarized, and here is a screenshot of a macro:

I assume the parenthesis, comma, and multiply in the macro definition were supposed to be highlighted like normal?

I feel it is perhaps counter intuitive to highlight something like a variable differently where it is declared compared to where it is used. The problem of course is that, like you say, you cannot parse C with regexp. It would require an actual parser to know what is a variable, what is a function, or what is a macro.

[abusalimov]

Yeah, I just tried these examples with Solarized.

I'm pretty sure that the unusual highlighting of macro body ((param1 * param2)) is an issue of the color scheme, not syntax. Sublime C Improved attaches meta.preprocessor.macro.c scope to the preprocessor directive, and I followed a description of meta scopes (from tmLanguage naming conventions):

Sometimes the meta part of the scope will be used only to limit the more general element that is styled, most of the time meta scopes are however used in scope selectors for activation of bundle items. For example in Objective-C there is a meta scope for the interface declaration of a class and the implementation, allowing the same tab-triggers to expand differently, depending on context.

I'm confident that there must be a scope for a source part like preprocessor directive (as for a function). I'm used to use Ctrl+Shift+Space to select the whole, even multi-line, macro, for example. And the only suitable scope for that I can imagine is meta.preprocessor, though I wonder about reasons behind the choice of Solarized developers to highlight it that way.

I feel it is perhaps counter intuitive to highlight something like a variable differently where it is declared compared to where it is used.

I guess this is pretty subjective, because it feels natural to me. I miss (and you too probably) a proper "goto declaration" feature in Sublime, and I find it rather useful to be able at least to recognize a declaration visually. I even have an idea of implementing a poor man's goto variable declaration plugin based on scopes (I mean just jumping up to the nearest word occurrence with an appropriate scope). That is, scopes are good, in general. :)

Nevertheless, I'll try to fix the original issue eventually, among with few more problems that I was able to catch with Solarized, like these:

Are you related to Solarized development somehow (I saw some contributions)? Anyway, what can you say on highlighting meta scopes like a macro body?

[abusalimov]

You know, I've come to realize that I actually don't want to implement highlighting of variable initialization as long as I see no way to implement it good enough. There're too many corner cases and false positives (that usually annoy rather than help), even in simple and commonly used snippets.

The question on highlighting macros is still open (though a bit off-topic), so I'll leave this issue open for a while.

[jibsen]

I am not involved in Solarized development other than being a user of the theme, and trying to fix the issues that affect me.

I imagine the highlighting of meta.preprocessor.macro.c in the Sublime theme is an attempt to mimic the screenshot on the Solarized homepage, where a define is colored orange. But I agree it would be better to detect the elements inside the meta scope and color them.

I don't have much experience with the way the grammars work, but I can see there appear to besome shortcomings -- for instance there is no keyword.operator.arithmetic for C. There could be reasons for this of course, perhaps it is difficult to differentiate between for instance multiply and pointer dereference.

[abusalimov]

I imagine the highlighting of meta.preprocessor.macro.c in the Sublime theme is an attempt to mimic the screenshot on the Solarized homepage, where a define is colored orange. But I agree it would be better to detect the elements inside the meta scope and color them.

I guess, you're right. It would be enough to limit this highlighting to entity.name.function.preprocessor and entity.name.constant.preprocessor. However, I also tried Solarized on Vim and it behaves the same (coloring the whole body of a macro).

BTW, I added highlighting of operators in 7b4db41f462e6fa3801f5348c848ddac78090c2f (available in v1.3.0), please check it out. It doesn't recognize a difference between dereferencing and multiplying (*) or between getting an address and bitwise AND (&), of course, but anyway all operators are usually styled the same way, so no one will notice a difference.