The symbol list is populated by a combination of the syntax definition and a separate metadata file that tells Sublime what parts of the language are symbols worth looking at.
If the syntax definition can distinctly recognize the items that you want in the symbol list (that’s generally the case if the color scheme can apply a style to just that particular text), then you’re probably just missing out on the metadata information. You should only need to modify the syntax definition if it doesn’t already match what you’re trying to capture.
As far as the metadata information goes, that requires a tmPreferences file that associates a scope selector with a setting that tells Sublime that the symbols that match the selector should appear in the symbol list.
As a simple example, you can use View Package File from the command palette to open Python/Symbol List.tmPreferences; the content of that looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>name</key>
<string>Symbol List</string>
<key>scope</key>
<string>source.python meta.function - meta.function.inline, source.python meta.class</string>
<key>settings</key>
<dict>
<key>showInSymbolList</key>
<integer>1</integer>
<key>symbolTransformation</key>
<string>
s/class\s+([[:alpha:]_][[:alnum:]_]*.+?\)?)(\:|$)/$1/g;
s/(?:async\s+)?def\s+([[:alpha:]_][[:alnum:]_]*).*/$1\(…\))/g;
</string>
</dict>
</dict>
</plist>
This metadata tells Sublime that any text that matches the scope selector provided (non-inline functions as well as classes) should appear in the symbol list. By default the symbol list will show you the text as it appears in the file; the optional symbolTransformation can be used to modify the text that appears in the symbol list.
The name of the file doesn’t matter (so long as the extension is correct) but it’s common practice to name it something like the above so that you can tell what it’s doing easier. For more examples of what’s possible you can look at some of the other metadata files the same way.
The Package of the file doesn’t matter, nor does the name of the file (so long as it has the correct extension), so you could create a file in your User package (or perhaps submit a PR upstream to the package author) that has the appropriate content to get things working.
