sublimehq / Packages

Syntax highlighting files shipped with Sublime Text and Sublime Merge
https://sublimetext.com
Other
2.95k stars 587 forks source link

[C++] missing scopes #409

Open DolphinDream opened 8 years ago

DolphinDream commented 8 years ago

Currently there are no scopes defined for these cases:

myClassA myObject;
myClassB* myObjectPointer;
std::vector<myClassC> myVectorOfObjects;
std::vector<myClassC*> myVectorOfObjectPointers;

And there is no differentiation between the class name and method name scopes (currently they are both represented by the entity.name.function.c++ scope): void myClassA :: myMethodB(type var)

There are no scopes defined for templates: DataStore<Surface*>::Delete(surfaceTag);

where DataStore is a templated class. The above access the Delete method in the templated class for the template of type Surface (also a class).

DolphinDream commented 8 years ago

Also the static member var declaration scopes are not represented:

float MyClassA :: myVariable = 1.0f;

wbond commented 8 years ago

In:

myClassA myObject;
myClassB* myObjectPointer;

the * and ; are scoped.

In:

std::vector<myClassC> myVectorOfObjects;
std::vector<myClassC*> myVectorOfObjectPointers;

the ::, <, *, > and ; are scoped.

I would expect the myClassA::myMethodB to be scoped as entity.name.function since it specifies the function being implemented. Do you have an example of what you were expecting to see on myClassA or myMethodB?

Using your example:

DataStore<Surface*>::Delete(surfaceTag);

I see scopes on <, *, >, ::, Delete, (, ) and ; with a meta scope on ::Delete(surfaceTag).

For:

float MyClassA :: myVariable = 1.0f;

I see scopes on float, ::, =, 1.0f and ;.

wbond commented 8 years ago

My guess is that perhaps you were expecting different or additional scope information.

If you can specify what you were looking for, we can discuss and see what may make sense to add.

DolphinDream commented 8 years ago

Ok, let me be more specific:

For

someType MyClass :: myVariable = 1.0f;

These are member variables declared statically in the class declaration (header) and defined/initialized in the source file. I expected someType, MyClass as well as myVariable to be scoped. Currently these are all scoped as source.c++ . Looking at the same code in emacs I can see these scopes are represented (colored differently). See the attached screenshots comparing Sublime vs Emacs highlighting in this case.

For the template function calls:

DataStore<Surface*>::Delete(surfaceTag);

For DataStore and Surface I get the same scope: source.c++ meta.function.c++ meta.block.c++ meta.block.c++ meta.function-call.c++ meta.group.c++ I expected these two (if possible) to have their own scope, not the larger meta scope.

See the attached screenshots comparing Sublime (top) vs Emacs (below) highlighting. Emacs seems to identify both DataStore and Surface with their own scopes.

For class member declaration:

myClassA myObject;
myClassB* myObjectPointer;

Both myClass and myObject are currently scoped as: source.c++ meta.class.c++ meta.block.c++ and i expected they would each have their own scope. I would think these should be scoped the same as the regular types (e.g. float myVariable, which have the scopes: source.c++ meta.class.c++ meta.block.c++ storage.type.c and source.c++ meta.class.c++ meta.block.c++ variable.other.readwrite.member.c++ respectively). sublimescope-template sublimescope-staticmembers

wbond commented 8 years ago

The reason we haven't traditionally scoped variables in C/C++ is that it is rather difficult to know what is a macro, what is a variable and what is a type. This is largely due to the C preprocessor.

My hope is to be making some revisions eventually to C/C++ to try and properly detect some additional elements such as type names and distinguishing between * as a multiplication operator and * as a pointer.

As I go through the various languages that need more drastic work (C#, Java) I'll try to see what existing languages are using for scopes on such things as static member access and generic types to see how we can make them more consistent, and more style-able.