This is what BracketHighlighter does:
- On startup: start a thread to watch for view changes or selection changes and intialize the matcher object
- On view focus: determine which rules etc. it needs to load up for the focused files
- On selection: match and optionally run bracket plugin modules as requested
There is one thing that takes a second or two, and that is creating a unicode table for unicode property support in regex rules (like this r"\p{Ll}\p{Lu}]"). But it happens only once, and I now defer it until the first call to use it, then it shouldn’t happen again unless the plugin gets reloaded. Deferring this allows ST Gui to load up without any lag.
ST Startup will probably do all these things:
- Startup: causing the BH plugin to load (pretty quick)
- Load views and focus one causing BH to load up rules (also negligible; try switching tabs, this causes BH to this)
- Places cursor in view which causes BH to do its first match causing the initial unicode table to load and then perform the match (this will cause the unicode property table to initialize)
Hardcoding the unicode table can probably help in the first view load time, or maybe caching that. I am sure this could probably just be loaded once, and then pickled for later use…
The plugin is surprisingly complicated to allow for all the different tweakable stuff and to be general enough to allow people to add their custom brackets via the settings files and/or specialized functions via bracket plugins. In general though, I don’t notice performance slow down because of the plugin. Probably the unicode table loading is the one thing that takes a couple of seconds.
If I get some time, I may look into caching the unicode property list. I also take pull requests .