Hi
When I press Ctrl+R (Go To Symbol), sublime shows a list of function declarations which is including function calls. It looks like sublime is show all functions with the scope entity.name.function instead of only looking at the meta scope meta.function.declaration.
Is it possible to hide the function calls with e.g. meta.function.call from the Go To Symbol?
Thank you
function calls shouldn’t get scoped as entity.name, check your syntax definition
https://www.sublimetext.com/docs/3/scope_naming.html
Function names, including the full path, and all parameters should receive the scope
meta.function-call. The name of the function or method should bevariable.function, unless the function is scoped with ***support.function***.
That I saw and it makes sense in some languages like javascript where you can literally assign a function to a variable, on others, it feels wrong to name the function being called as a variable.
The variable scope really means “user-defined name”. It’s used for variables, constants, classes, functions, and pretty much anything else.
To add to this, it is mostly for historical/backwards compatibility. If we were going to just come up with our own scope names, I am sure we would probably pick something different, but alas we need to try and maintain some compatibility with the syntaxes and color schemes in the wild, otherwise everything will look “broken” to users.
That’s exactly what I am having trouble with, I want to normalize the scopes from my syntaxes to the ones in the catalog you made, but I also want to be able to create color schemes where I could target very specific tokens e.g. destructuring vs blocks, array literal vs property access, etc… an example I had trouble with:
var = a = [b['...']]
The external brackets have the scope meta.sequence punctuation.section.brackets, the property access is meta.sequence meta.brackets punctuation.section.brackets where the meta.sequence is bleeding from the array literal being declared which can give headches on more complex expressions if you are trying to target the former or the later.
FichteFoll made a great tool to create complex color schemes but we still need cleaner scope stacks(not letting meta scopes bleed) to prevent issues like the previous one.
Do you think it is possible that we create some sort of “scope specification” per programming language from the syntaxes you already made and reduce meta scope bleeding? A github repo having all scopes specified per programming language where people could look when designing a syntax or color scheme, suggest scopes for new tokens in evolving languages and try to sort out problems like the one I mentioned.
The prefix names are really only the start of the hierarchy. Could you get some benefit out of creating your specifications for the lower tier words as well?
For example:
meta.function-call – The base scope name for a subprogram call.
meta.function-call.procedure.vhdl – One variation on the first
meta.function-call.function.vhdl – The second valid variation.
Thus a color scheme could target the specification meta.function-call, but you could create a more specific color for meta.function-call.procedure if you wanted to draw more attention to it.
Maybe I’m not following along very well, but it does seem like the scope name recommendations are only the tip of the iceberg – sort of the lowest bar to clear for a color scheme and that there’s a lot more room for specificity if you like.
I understood the reason they are using variable.function in other syntaxes and agreed with it.
What I proposing now is a specification(not a suggestion, a fixed set of scopes) controlled by the sublime devs that people can follow when creating or fixing the syntaxes and allow specific scopes to solve the issues like the array literal I talked.
I created a syntax that combine javascript, jsx and react because I needed specific scopes, I needed different colors for very specific tokens and I realized some days ago that other people did create a javascript syntax to solve a similar issue of the lack of scope specificity.
Unfortunately it wasn’t clear to me from your description what the issues you were describing are.
Generally the combination of specializations of scope names (variable.function.method vs variable.function) or stacking (meta.brackets meta.function-call meta.brackets) should allow you to target specific situations. Specializations are the best tool, IMO, because people who don’t care about the different between a method and function, or anonymous function, etc can just use variable.function. However, specialization of scopes usually requires more duplication in the syntax, which can lead to issues with maintainability.
Based on your comments, however, I think I am misunderstanding part of the issue you are running into.
I’m also not sure what a “not a suggestion, a fixed set of scopes” would mean? I don’t think we can enforce anything with third-party syntaxes, just the default ones we develop on GitHub.
The function call scope is solved, I agreed with you and I’ll use variable.function.
What I am talking now is if it possible to create a standard in the core e.g.:
function identifier({a,b,c}){}
// ^^^^^^^^ storage.type
// ^ destructuring punctuation.block.begin
Where we have the scopes specified per language, I know that there’s no way to enforce but a document(simplified, not unit tests) that states the expected scopes. This would make it easier for external syntaxes to use standard scopes and easier to find bugs even in the core syntax.
I’ll correct my syntax scopes to the ones in your catalog but there are a lot of them missing(e.g. destructuring), so I also want to reach an agreement on the specific scopes (like the array literal/property access problem).
Consider the javascript array literal, meta scopes are not working to differentiate array literals from property access in complex expressions because they are applied to the array values too(consider meta.brackets example I talked before, the meta scopes stack and then you get a bracket that could either be property access or array literal). To solve this we could either limit the metascopes to the array punctuation only and prevent stacking or have new and more specific scopes.
Consider the javascript array literal, meta scopes are not working to differentiate array literals from property access in complex expressions because they are applied to the array values too(consider meta.brackets example I talked before, the meta scopes stack and then you get a bracket that could either be property access or array literal). To solve this we could either limit the metascopes to the array punctuation only and prevent stacking or have new and more specific scopes.
The selector meta.brackets.js punctuation.definition.js should score higher than meta.sequence.js punctuation.definition.js. Shouldn’t this suffice to differentiate them?
I think it’s perfectly reasonable to seek a community consensus on more-detailed scopes. I don’t think that it’s necessary for the Sublime devs to set all of this in stone. The official guidelines are conservative and (deliberately) slow to change. Why not let the community establish the cowpaths before worrying about having them paved?
So if I were going to put this in core, I would probably add something to the scope naming guidelines along the lines of:
meta.destructuring - used when accepting a sequence of values into multiple variables in a function or method definition
As long as we have general agreement from a handful of core contributors to the default syntaxes, I am fine with adding additional scopes to our guidelines. Sometimes things get tricky, because different languages will use the same name for different features, and then we have to try to find a generic, or most common term to explain the item. Probably one of the more complex situations recently was for annotations/attributes/decorators. They all function similarly, and users should generally expect them to look similar in different syntaxes, but different languages use different names.
In these types of situations, feedback and input from different syntax authors is appropriate. Sublime HQ will end up being responsible for the final decision, but usually the community (with our involvement) can come up with a solid proposal and we can get to work enhancing the default and third-party syntaxes.
Incidentally, I’m working on enhanced destructuring support in the core JavaScript syntax. There has already been some discussion about proper scoping for bindings in JavaScript; once the new functionality is working we’ll be in a great place to make scoping decisions. It will probably be complete two builds from now; there’s currently a pile of JS-related PRs at the moment and I don’t want to make too many changes and risk conflicts.
The idea would be having a repo dedicated to the scopes so that people could raise issues on the scopes alone and suggest new ones, I thought about the sublime core devs having a final saying because they already experienced conflicts between multiple languages.
I saw your work and I am implementing your expression head-tail logic in my syntax(worked beautifully thank you) but don’t worry about fixing the scopes from the syntax right away, we just need a plan to know how the scopes should be then we can worry about fixing the inconsistencies.
Currently https://github.com/sublimehq/Packages is the place to do this. We’ve already got a bunch of active contributors, and I check it regularly.
Would it be possible to add possible documents that specify scopes per language there? e.g create a directory “Scope Specification” and inside there add documents for each programing language, something that deals only with the scopes where other people can check the exact catalog for each language.
I could try to help with that as I believe many people will benefit from not having to go through unit tests or checking scopes manually while also allowing discussions on the scopes alone.
Hmm, I think we are on a different page here. We don’t really want language-specific scopes. We want everything to be generic (even if it doesn’t apply to all syntaxes), so that multiple syntaxes can share scope names and people aren’t creating color schemes for specific syntaxes.
All of the naming guidelines are explained at http://www.sublimetext.com/docs/3/scope_naming.html. If anything, I think it would make more sense to try and get some of our docs available on GitHub to accept issues/PRs.