@wbond I just wanted to say that I’m a bit surprised about the new official scope conventions
It writes:
The names of data structures will use one of the following scopes, or a new sub-scope of `entity.name` – this list is not exhaustive. To provide rich semantic information, use the specific terminology for a given language construct.
Avoid `entity.name.type.class` and `entity.name.type.struct` which unnecessarily nest scope labels under type.
entity.name.class
entity.name.struct
entity.name.enum
entity.name.union
entity.name.trait
entity.name.interface
entity.name.type
For me the goal of the scope name was to abstract language conventions away from Color scheme writers and plugin developers, and you are going in the opposite direction.
An example of what could be achieved with more coherent scoping is this plugin for inserting Doxygen comments in a file.
In this plugin I ask Sublime to find the part of scope matching some broad scopes not specific to a language and use them to insert a documentation.
public class Foo {
public void Main(String someArgument){ ... }
}
Becomes:
public class Foo {
/// <summary>Main summary</summary>
/// <param name="someArgument">someArgument</param>
public void Main(String someArgument){ ... }
}
I wrote this long ago and the code is far from perfect, my point is that a developer from language X could write a plugin that works with several language at once without worrying about differences in C++ between a class and a struct.
I’m afraid that the documentation in the current state encourages people to overfit the scopes to their languages and to not care about the conventions used by plugins and schemes.
I think the entity.name.type was something quite clear, that can benefit from refinement but in a nested way ( entity.name.type.xxx). I agree that these scopes were a bit long but now I have to write entity.name -entity.name.function -entity.name.namespace instead of entity.name.type I’m not sure that’s a win.
