Hide function calls from Go To Symbol

[Remi]

I ended up using the following in VHDL for subprograms:

meta.block.procedure.specification.vhdl
meta.block.procedure.body.vhdl
meta.block.function.specification.vhdl
meta.block.funcitonl.body.vhdl

These seemed to fit because these are block declarative items. Separating the specification and body out is due to the fact that VHDl does have something analogous to a prototyping system. Anyway, I think there can be some value to languages that have specific subclasses of subprograms to further specify. I’m not sure whether in my case meta.function is any better than meta.block. I’ll have to think about this. (Honestly I would prefer meta.subprogram simply because Python has methods, Java has methods, C has functions, VHDL has functions and procedures, Pascal has functions and procedures, etc. They’re all loosely subprograms. But I suspect the ship has sailed on that one.)

[borela]

Yes it would conflict with other specializations. I guess the only way would be to wait for the > operator to be added or have another meta scope to envelop the methods.

[borela]

I like the idea of having the function.body as a specialization for meta.block as it would serve as a fallback too if punctuation.section.block has no color defined.

[Remi]

I think I would reserve that for languages that have a formal body defined. To be perfectly honest, in my language there are several lexical zones. There’s the type (I used storage.type) of subprogram, the identifier, a parenthetical group of parameters. And then if that’s the declaration, it ends there (loosely analogous to a C prototype). However if it’s the specification, it contains all that, then a block declarative zone for local objects, and then a begin keyword to define the body properly, followed by a set of sequential statements, and an end.

For me, the body is a very specific zone where I permit and lexically scope valid statements. It could vary language to language, and maybe that’s all for the good. The trouble with all of this is that you need a generic system to cover a number of languages broadly, however need specificity to handle the intricacies of the languages once you drill down into their definition.

[ThomSmith]

One thing that’s been discussed is a meta.declaration scope. A JavaScript function declaration would be meta.declaration.function meta.function, while a method declaration might be meta.declaration.method meta.function or meta.declaration.function.method meta.function. A function expression would be simply meta.function with no meta.declaration scope.

The intended meaning of meta.declaration would be “a thing defined within and exposed without”. It could cover function declarations, class declarations, variable declarations, type declarations, and more. Not every language would contain every type of declaration, and in some languages some declarations might be synonymous with another scope – for example, C lacks first-class functions (last I checked), so every meta.function would be contained in a meta.declaration.function. But C++ has lambdas, which are functions but not function declarations. As another example, Python lacks variable declarations altogether (except for the global statement).

[borela]

I like your idea of having meta.declaration scope specially the meta.declaration.function.method for methods as it could allow color schemes to highlight methods as normal functions if a specific rule for them does not exist.

[borela]

Is it possible to show the variable declarations in the Ctrl+R? Are they hidden by design?

[addons_zz]

You just need to create a configuration file putting they there. Example AmxxPawn_Local.tmPreferences:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>name</key>
	<string>Symbol List Local</string>
	<key>scope</key>
	<string>(source.AmxxPawn | source.sma) &amp; (variable.local.definition | parameter.definition | function.definition | variable.definition)</string>
	<key>settings</key>
	<dict>
		<key>showInSymbolList</key>
		<integer>1</integer>
	</dict>
</dict>
</plist>

[borela]

Is it possible for function declarations to have the meta.declaration.function scope to envelop the body(you can see an example here) but hide it from the indexer?

I created a repo to show an example of what the reverse documentation could look like, it’s like the syntax tests but simplified, grouped by feature with added notes.

[borela]

To enhance compatibility with HTML color schemes, I am scoping JSX as if it were HTML but adding the suffix “JSX” to the end text.html.basic.jsx.

Is it a good idea? Is there a better alternative? Another thing, the HTML syntax that ships with sublime doesn’t let the meta scopes stack, so:

<div>
  <span></span>
</div>

The span would have the following scopes:

text.html.basic 
meta.tag.inline.any.html 
entity.name.tag.inline.any.html

Instead of:

text.html.basic 
meta.tag.block.any.html
meta.tag.inline.any.html 
entity.name.tag.inline.any.html

Which would include the meta scope from the div, is it by design? Is it an error? In javascript most metascopes(meta.function comes to mind) would envelop the inner contents of the structure doesn’t matter how deep it is.

[ThomSmith]

I would not scope JSX tags as HTML. They aren’t, despite the resemblance; the syntax is subtly different and the semantics are vastly different.

I think it makes sense to nest scopes. HTML is a messy language, and it’s very difficult in general to get tag nesting right. JSX is cleaner; like XML, all tags must be closed explicitly. However, I would use meta.tag only for the open and close tags themselves and use a new meta scope (meta.element?) to denote the entire extent of the element, including the open tag, close tag, and contents.

[borela]

I would not scope JSX tags as HTML. They aren’t, despite the resemblance; the syntax is subtly different and the semantics are vastly different.

I know, I am only using text.html.basic.jsx to give support for most color schemes without forcing them to add a specific rule for JSX. Here’s an example:

I clear the source.js scope and add the scopes as if JSX was HTML, when an embedded {} JS code begins, the syntax clears the scopes again and highlights it as a normal javascript.

This makes the JSX tags compatible with most color schemes, if I add something like source.js or source.jsx, suddenly that white text inside the tags changes the color because of the default color per language, and this happens in a lot of color schemes.

I think it makes sense to nest scopes. HTML is a messy language, and it’s very difficult in general to get tag nesting right.

Definitely, I am not sure the effort to apply all HTML rules(except for the basic ones like img tags not having a closing tag) justify how complex the syntax would’ve become.

[ThomSmith]

if I add something like source.js or source.jsx, suddenly that white text inside the tags changes the color because of the default color per language, and this happens in a lot of color schemes.

This is a new one to me. There are color schemes that blanket-color source or source.js differently from text?

[borela]

Yes (not in material theme that I was using), in some schemes the text gets different, other the attribute strings shows a different color (I guess they have different colors for HTML strings and JS strings), and there are more subtle examples like the div has a different color:

if I remove the source.js source.jsx, it shows works as expected: