Sublime Forum

Scope Naming Clarification

#1

I have some questions on the meta section in the Scope Naming.

The entire scope of a function should be covered by one of the following scopes. Each variant should be applied to a specific part, and not stacked

Is this how I should interpret it?

public void myFunction(bool foo) {
// <- meta.function
//     ^ meta.function.return-type
//     ^ ! meta.function
//          ^ meta.function entity.name.function
//                    ^ meta.function.parameters punctuation.section.parens.begin
//                    ^ ! meta.function
//                              ^ meta.function.parameters punctuation.section.parens.end
//                                ^ meta.function punctuation.section.block.begin
    ...
}
// <- meta.function punctuation.section.block.end

Does having a meta.function scope even make sense if it’s broken out into so many little pieces? Or am I interpreting it wrong?

0 Likes
#2

meta.function should match the entirety of public through }. Certain parts should be “specialized” to things like meta.function.return-type or meta.function.parameters.

You can see an example at https://github.com/sublimehq/Packages/blob/master/Go/syntax_test_go.go#L185-L208.

0 Likes
#3

Thanks for the example. I got thrown off by the each variant should not stack.

Hijacking the thread, not sure how I would wrap everything in a meta.function for Java.

@SomeAnnotation
public Foo
    myFunctionaNameThatIsReallyLong(bool foo) {
    ....
}

@SomeAnnotation
private Bar myVariable = new Bar(2);

private <T extends Bar> Foo
    genericFunctionWithALongName(T bar) { ... }

/* package protected */
@SomeAnnotation
Foo anotherFunction(bool bar) { ... }

@SomeAnnotation
Bar myVariable;

In java there is no indication that a declaration is a function until I encounter a (. Is there a way of backtracking to add a meta scope? Or is there a generic meta scope I should add around the entire declaration?

0 Likes
#4

Unfortunately in some languages you can’t accurately add meta scopes to the return value since you don’t know if it is a variable declaration or function until later. Due to the way the syntax highlighting engine works, it is not possible to alter the scopes of a token once it has been consumed, as that would result in backtracking.

Syntaxes that explicitly denote functions and data types by leading keywords are obviously much easier to deal with.

0 Likes
#5

Would it be helpful to standardize more subscopes than parameters and return-type? (Currently, only these are specified in the docs.)

For instance, in most languages you could find the name of the function by looking for entity.name.function. However, in JavaScript, a method declaration may look like:

['my' + 'Function']() {}

In this case, having a meta.function.name scope would be appropriate. Other possible subscopes could be meta.function.body (especially helpful for languages like JavaScript where a function body may or may not be wrapped in braces) and meta.function.access (which might include multiple keywords such as protected internal). Different languages might not use all of these (just as they don’t all use meta.function.return-type).

The same may apply to other scopes. For instance, meta.class could have subscopes of meta.class.name, meta.class.inheritance (especially for languages like JavaScript where this could be an arbitrary expression rather than a simple class name), meta.class.body, meta.class.access, meta.class.type-parameters, and so forth.

Of course, not every syntax need implement this level of detail. And authors could just make up their own subscopes for these purposes – but consistency is good.

1 Like
#6

I’m definitely open to proposing further additions and refinements to the scope naming guidelines. That said, the more specific it gets, the more difficult to standardize due to language semantics and differences.

https://github.com/sublimehq/Packages/issues is probably the best place to discuss possible enhancements. If you open an issue, I can tag it as RFC to get feedback from contributors.

0 Likes
#7

I like this idea and in fact already made use of the meta.function.name as my G-Code syntax supports composed function names, too. I also introduced a meta.function.attributes section for general attributes being attached to a function definition.

1 Like
#8

Thank you.

0 Likes