I have to say I never worked with very big projects. Still I think that having an expanded selective index wouldn’t be useless, you can achieve a lot by creating a selective index(filtered for chosen selectors), built from the Sublime index, but with additional informations that you retrieve directly from files, especially if files are indexed one by one (with an on_save listener for example). Also, having all symbols in autocomplete without some kind of filtering isn’t something I’d like, personally.
To make it in a way that it doesn’t cause performance issues, I was thinking something like this could work. Assuming you have a json file where you will store all indexes, initially empty.
-
palette command: Project Autocomplete: Track current project. It will then look the symbol index and extract the ones that are present in the current file. It will then build a list of selectors from this list of symbols(checking the selector of the row/col point stored in the index), and prompt you to choose which selectors you would like to index for this project. So you’re starting to index this project, and only the words that match the chosen selectors.
-
the command would write to the json file: the name of the project and the chosen selectors, adding already the strings of the symbols in the file that match the chosen selectors, excluding all others.
-
after that, the only work done in the backgroung would be in an on_save listener: when a file is saved, ST index is searched for symbols that belong to the current file, the string is extracted from the view for symbols that match the chosen selectors, they are added to the project autocomplete list, and the json file is also updated (so that on Sublime restart your index is still there). If you want to index files with a certain extension and exclude others, you could do it, and further decrease performance impact.
-
you could have another palette command like: Project Autocomplete: Add selectors from current file. A similar job as in the other command would be done, but it would only add from the current file, also for extensions/selectors that you don’t want for other files.
This index would be expanded as you work on the project, edit and save files. It would be a partial index unless you open and save all files, but I don’t think it would affect performance much or at all, the on_save listener would run a command that scans the current file asynchronously. It wouldn’t be like having the same from the API, but it’s something that can be done already. Moreover, it’s not guaranteed that an expanded built-in indexing wouldn’t cause performance issues less than a plugin.
If you do it by plugin, you have an initial limitation (partial index) but you could restrict autocomplete to chosen selectors (much lighter for a big project) and could do some more stuff. For example, if you index functions you can store parameters as well, and then have parameters autocompletion with a special keybinding (as ctrl+tab), snippet-like. I’m doing something like this in a plugin, and it works well but only from a pre-built file with all autocompletions.
For example if I set the autocompletion string to:
score_selector(${1:scope}, ${2:selector})
autocomplete would only show score_selector and complete that word with tab, but if I hit ctrl+tab it would launch a snippet with the whole string as content. The snippet string would be built from extracted string and accompanying parameters in the case of functions.
I don’t know if there’s some Python library to extract scopes/selectors from a file position, if there is, you could index the whole project in one go, starting from ST index, without actually opening the files in ST.
