Sublime Forum

Hide function calls from Go To Symbol

#41

I would create selectors with:

  • meta.class punctuation.section.block
  • meta.class meta.method punctuation.section.block

Those may not be 100% correct, but you get the idea. A larger number of scopes results in a stronger match. For some things this isn’t doable, but definitely would work for class/method where you know what the structure will be.

However, as I’ve mentioned before, specialization is the strongest option here. However, you are going to need to make your syntax more complex in some situations, since you can’t just include a previous context with the matches you need.

0 Likes
#42

Specialization could be short term route until support for the > operator is not added, What do you think of these scopes?

punctuation.section.block.class.body 
punctuation.section.block.method.body
punctuation.section.block.arrow-function.body
punctuation.section.block.function.body

Is it good? bad? Are there better alternatives?

0 Likes
#43

I don’t think we’d add them to the default syntax, since it will likely take less effort to add the > operator. However, keep in mind that some color schemes are going to expect .begin and .end labels, so you probably want to put those specializations after .begin/.end.

Also, I likely wouldn’t do arrow-function, but function.arrow.

1 Like
#44

Is meta.item-access a standard scope? If we come to a conclusion here, I could simply add it to the core JavaScript syntax. Likewise with punctuation.section.brackets.begin.item-access and so on; some discussion would probably provide a sensible set of recommended specializations that would be useful across a range of languages.

A > operator could be extremely useful, for tooling as well as for color schemes. However, if implemented like in CSS, it would cause tools to break if new unrelated meta scopes were added. I explored this kind of logic once for a lexically-aware autocompleter, and what it turned out in the end that I really needed was a bit more complicated.

If there is a possibility of extending the selector syntax, there are definitely opportunities for useful new features, especially when dealing with complex syntaxes with a lot of specialized meta scopes. For instance, what about matching punctuation.*.open to get all open parens/brackets/braces/whatever? Distilling such ideas into a simple, coherent set of extensions could be a discussion unto itself.

2 Likes
#45

Currently it is in use in the Python syntax. I can’t recall off of the top of my head if we use that, or some variant in other syntaxes. @kingkeith probably recalls if we do for C#, and @ismell may recall for Java. It doesn’t appear we do anything special for C/C++, but that (and Rust, probably D, Go) have the interesting aspect of type definitions using something that looks similar for array sizes. Rust also allows them to define macro bodies, but then again Rust has some complex syntax and uses symbols in many different ways.

0 Likes
#46

Java uses meta.brackets for array accessors: https://github.com/sublimehq/Packages/blob/master/Java/Java.sublime-syntax#L152
I think meta.item-access would be fine. How does that play with punctuation.accessor.dot?

0 Likes
#47

C# currently just uses meta.brackets:

0 Likes
#48

When updating the method scopes, as suggested, I added meta.method to be able to target the parenthesis and braces:

class MyClass {
   myMethod(){}
// ^^^^^^^^^^ meta.function.declaration
// ^^^^^^^^^^^^ meta.method
//         ^  punctuation.section.group.begin
//          ^ punctuation.section.group.end
//           ^  punctuation.section.block.begin
//            ^ punctuation.section.block.end
}

Which scope should add if I were to give different colors to parenthesis and braces for a constructor or a special ReactJS method? Maybe:

meta.method.language or core?
meta.method.lib.react-js
0 Likes
#49

I think that meta.function should cover the entire method declaration, including the body. In other languages it does; I think that this is a bug in the JavaScript syntax, but I declined to fix it because I didn’t want to change the syntax tests unnecessarily while the restructuring was in progress. If this is indeed a bug, then I’ll add it to my to-do list.

There’s a bit of a backlog of JavaScript PRs at the moment because the Sublime devs are focused on a critical Mac OS GPU issue. Within the next couple of builds I’m hoping to get the new binding code out and then pluck the remainder of the low-hanging fruit (mostly adding ES6+ features). Once that is done, I think we’ll be in an excellent position to add meta scopes in accordance with new developments in other syntaxes with minimal risk of conflicts.

As far as third-party-specific features, I don’t think that we should add them to the core syntax and I wish we didn’t have the ones that we already do (though modifying them now could be a breaking change for many users). I’m working on a new package that uses a novel approach to address this issue systematically, but I don’t want to make any promises until it’s ready for beta, which could be several weeks in the worst case.

0 Likes
#50

I’ll add to my syntax, I want to agree on a specific structure because you guys know which ones will give the best backwards compatibility, plus, if in the future you decide to add this in core (like in the case of the constructor), the syntaxes will be sync already.

0 Likes
#51

have you seen how C# does constructors?

0 Likes
#52

It uses meta.method.constructor.cs for the parenthesis but no special scope for the body:

First parenthesis for the parameters:

source.cs 
meta.class.body.cs 
meta.block.cs 
meta.method.constructor.cs 
meta.method.parameters.cs 
punctuation.section.parameters.begin.cs

First brace for the body:

source.cs 
meta.class.body.cs 
meta.block.cs 
meta.method.body.cs 
meta.block.cs 
punctuation.section.block.begin.cs

Couldn’t we have something more generic for these language features like meta.method.language or core? For example, C# has operator overloading and having a different color for the punctuation (){} could be useful.

0 Likes
#53

If you apply meta.function.declaration to the body, it appears in the goto symbol(Ctrl+R), I deliberately stopped after the return type because of that.

function myFunction():number {return 1}

Ctrl+R lists it in my syntax as:

function myFunction():number

If I add meta.declaration to the body, it would include the return too.

0 Likes
#54

The entire function should be meta.function. We can leave meta.function.declaration in place only on that initial part, or, better yet, change the Symbol List Function.tmPreferences file.

0 Likes
#55

Agreed, I am adding the meta scopes to my syntax and the meta.function is missing in the core too. As for classes, the braces are showing:

source.js 
meta.class.js 
meta.block.js 
punctuation.section.block.js

Is the meta.block necessary?

0 Likes
#56

Necessary, no; appropriate, arguably. I would like to see a meta.class.body, but I’m not sure if there’s a convention.

0 Likes
#57

To mantain compatibility with most color schemes, methods are marked as meta.function too, specially because of the meta.function.declaration to extract the declaration… should we add meta.method to methods or use the speciallization meta.function.method to allow different colors for methods?

0 Likes
#58

A while ago we concluded that using “function” instead of “method” im all cases was the way to go.

Why do you think you need to specialize this to “method”?

0 Likes
#59

In javascript is possible to have methods and functions, in most color schemes both would have the same color but it could interesting to allow the speciallization as some of them (Neon comes to mind) give different color to method identifiers.

0 Likes
#60

In JavaScript, any function declaration at the top level of a class body is a method. As a result, it isn’t necessary to use a different meta scope. Using meta.function.method could potentially interfere with other specializations, such as `meta.function.argument-list.

0 Likes