[Symbol Index] Similar test tool to st_syntax_tests for testing Symbol Lists

[willstott101]

Problem description

Issues with Symbols appear to be very common for sublime packages.

Whilst trying to resolve some problems with symbols in TypeScript, I've dearly missed the automated testing capability that we have for syntaxes.

Preferred solution

This is a feature request for a similar tool (or an extension) to the syntax tester which can be used to check which symbols would be indexed from a given file.

I imagine it might look something like this:

• @ for file-local symbols (the Goto Anything character)
• ? for indexed symbols
• & for indexed references (c++ inspired)

def func(from='me'):
#        ^^^^ invalid.illegal.name
#   @@@@
#   ????
    pass

a = func()
#   &&&&

[willstott101]

I haven't gone into too much detail about a potential solution as this is just a suggestion. If you're interested in a more fleshed out concept I would be happy to think about it.

EDIT: Specifically anything to do with transformations, or making sure references match up to specific definitions. Once we get into that we would have to consider multi-file tests - which I doubt is something worth pursuing until the whole index engine is more customisable.

[willstott101]

Actually perhaps @ for file-local symbols (the Goto Anything character), ? for indexed symbols, and & for indexed references (c++ inspired)

EDIT: I've updated the original post based on these characters

[michaelblyons]

There is slight problem with this. When running my tests locally in a "set up for me" Sublime Text, I may have some Packages/User/Stop indexing foo.tmPreferences file that reflects my local preferences and now my runs of the unit tests will always fail.

An issue surfaced yesterday when a .tmPreferences file in the Default Packages with no root (source.*) scope affected other packages. I don't know how to check for this kind of interference and exclude the User situation above.

Even so, it might be important to assert "not indexed" in a particular way. May I recommend a - suffix for this?

def func(from='me'):
    pass
#   @@@@ -

a = func()

@wbond suggested a different method for "not indexed" items: that a unit test might assume everything not affirmatively covered to be a "not" state, but that has the same problem as --suffix, and perhaps a worse one:

1. All existing syntax tests will fail until every single relevant item is marked with @/etc.
2. Any user-specific (or other package's) .tmPreferences modification will cause all its affected syntax tests to fail.

[BenjaminSchaaf]

This has been added in build 4087. Symbol tests use @ to signify which text to test. Symbols are split into 5 categories:

• "none": No symbol, for negative testing
• "local-definition": An unindexed definition, ie. it only shows in goto definition
• "global-definition": An indexed-only definition, ie. it only shows in goto symbol in project
• "definition": A definition that is both unindexed and indexed
• "reference": A reference.

When a symbol test is present every symbol must be tested for exhaustively. This can be turned off using partial-symbols after SYNTAX TEST.

Example:

void foo() {
//   @@@ definition
    foo();
//  @@@ reference
}
  this() {
//@@@@ local-definition
  }

[michaelblyons]

When a symbol test is present every symbol must be tested for exhaustively. This can be turned off using partial-symbols after SYNTAX TEST.

I am really curious what the effects will be for someone who installs a package (Emmet?) that indexes things in other packages.

[BenjaminSchaaf]

If a package changes the indexing rules for other packages the tests would presumably fail.

[deathaxe]

This means I now need to update 400 tests in Java to satisfy the syntax tests? :-O

[wbond]

The checks only kick in once you annotate at least one symbol.

[deathaxe]

Ah, I see. Added one, yes. So I have a task for another long cold rainy day.

[BenjaminSchaaf]

You also have the option of using partial-symbols, though it does reduce the benefit of the tests. Maybe the real task is creating automation for adding symbol tests for package dev ;)

[deathaxe]

Maybe the real task is creating automation for adding symbol tests for package dev ;)

Nothing else I had in mind. ;-)

[deathaxe]

• "none": No symbol, for negative testing

... does not work

[jrappen]

Negative symbol tests do not always fail anymore with Build 4147.