It may be that you needed to restart Sublime Text to get the indexers to pick up the new syntax. Or it is possible a spelling or capitalization issue caused the problem.
I’m referring to the Sublime Text Console, which is available on all platforms via View > Show Console.
I’m referring to the Sublime Text Console, which is available on all platforms via View > Show Console.
Found it, thanks! Hopefully others who come to this thread will join me in being just a little less ignorant thanks to your answers. 
It may be that you needed to restart Sublime Text to get the indexers to pick up the new syntax. Or it is possible a spelling or capitalization issue caused the problem.
Re-tried with JavaScript/JavaScript.sublime-syntax and re-enabled MarkdownEditing. Unfortunately, CPU usage spiked again. Note that I did not have a pre-existing JavaScript folder in ~/Library/Application Support/Sublime Text 3/Packages.
That is correct. Normally users shouldn’t. The process I described is creating an override for a package file, namely JavaScript.sublime-package/JavaScript.sublime-syntax. There is a little more info at http://www.sublimetext.com/docs/3/packages.html.
Makes sense, and that is what I understood to be happening. Thanks for confirming.
MarkdownEditing is not mission-critical by any means, so I can wait for a fix in release.
Just a note, I am looking into index_exclude_patterns right now, and have removed that recommendation for the time being.
It appears that right now index_exclude_patterns only applies to the file name, not the full path. Instead, binary_file_patterns can use used – see the example.
Sorry for initially recommending a solution that didn’t work.
I tried adding my problem directory to the binary_file_patters and now every time i try it open a file in that directory ST hangs. My whole project is basically all javascript, the filetypes are .jade and it tries (and fails) to index every .jade file i have. Currently ST is unusable for me. Is there a strait forward way to rollback to build 3114?
What Jade syntax are you using? Can you provide an example of a .jade file that causes ST to hang?
Have you tried installing a newer version of the JavaScript syntax, as discussed at [Solved] High CPU Usage in Beta 3124?
Here is an example of a .jade file
:doc
@name Toolbar
@props {Boolean} [left]
@props {Boolean} [center]
@props {Boolean} [right]
import './index.ess'
var classFn = this.composeClasses('Toolbar')
.Toolbar(className=classFn())
div(className=classFn('&-inner'))
if props.left
div(className=classFn('&-left'))
yield left
if props.center
div(className=classFn('&-center'))
yield center
if props.right
div(className=classFn('&-right'))
yield right
:module
export var mixins = [require('ui-kit/mixins/compose-classes')]
I haven’t tried updating my js syntax, i’ll try that now. Is there a way to reset the state on ST? i can’t open it currently because of the feature of re-opening files where i left off, so it re-opens a file that it is hanging on, and all i can do is force quit.
(FYI, i’m on OSX El Capitan)
You could wipe your Local/Session.sublime-session file, but you probably don’t want to do that. Installing the JavaScript.sublime-syntax override is likely to fix what you are running into.
Why wouldn’t i want to wipe the Local/Session.sublime-session file? I’m not worried about losing any changes, if that is the concern there.
It just kills all of your history (recent projects, searches, and more). Any adjustments you’ve made to the size of UI panels, or options, like the Find panel.
Well, i killed it, it was a choice between ST not working at all, re-installing, or just losing that, which i would have anyway for the other two options. Adding the Javascript.sublime-syntax override did solve my problem. Has the underlying problem been diagnosed? I have about 30 colleagues who will all have this issue when they update. I warned them all this morning to not update because of this
The underlying issue is that the Jade syntax uses regex constructs that aren’t supported by our newer regex engine. It ends up including the JavaScript syntax that ships with Sublime Text. That syntax uses a regex that works fine on a non-backtracking engine (like our newer engine), but once combined with the regexes from Jade it causes catastrophic backtracking in the Oniguruma engine.
Unfortunately it seems that none of the users of the dev builds utilize the Jade syntax, nor the MarkdownEditing syntax with fenced js code blocks.
I’m a dev build user and I refuse to use any syntax that won’t use the sregex engine, so that’s why I never discovered it 
it shows how important it is to get an even more diverse group of people on the dev builds though… consider using them, people!
Well that’s unfortunate. I’ll let my team know about the override. Anyway, thanks for all the help! I’ll check into using the dev builds, maybe i can at least cover the jade syntax issues.
lol and maybe some day i’ll have the luxury of choosing my syntax, but today is not that day. And, honestly i love the dev perks of using jade, it’s unfortunate that it’s conflicting so bad with ST
I guess I’m special in that I manage to find the time to hack together my own syntax that is suitable enough for my needs I don’t tend to regularly work on many different file types though, which makes it easier 
Hi WBond,
Thanks for the update…but I guess I’m kind of wondering if there is a bigger fix possible? I’ve been reporting the miserable experiences that indexing and broken plugins create for a long time now. For anyone developing NodeJS (and probably other dependency-heavy platforms as well), huge directory trees are the norm - not an edge case.
Could Sublime:
This is probably the 4th or 5th time I’ve had a situation where some change (plugin, new Sublime build, etc) causes my whole editing experience to grind to a halt, and the solution always involves hackily editing config files, looking under the hood etc. Surely my experience is not rare.
Could everyone install dev build 3125 and see how it helps?
We’ve included the JavaScript change, but also made some tweaks to the default number of index_workers. Jon created a new Help > Index Status… window to show all of the indexing activity.
We’ve got some more tweaks planned for the future, but hopefully these changes should help users experiencing acute behavior.
Fundamentally there really aren’t issues with large folder trees. I dogfood ST on a daily basis with projects of around 100k files and regularly work on the syntax definitions, where saving a syntax definition triggers reindexing.
We made a tweak in 3125 to the default number of workers that should address users who don’t care for fans spinning up on their laptops.
Sublime Text already sets indexers as low priority. While it is true that the indexers will use spare CPU, it shouldn’t really “take over” unless the OS has trouble scheduling. Our tweak to the default number of indexers should help reduce this symptom.
The Console shows errors in indexing, to allow the user to find issues with syntaxes. The progress of indexing is displayed in the status bar, and there is a new Index Status window in build 3125 allowing users to see exactly what is going on.
We’ve got some ideas about further ways we can make the indexing process even more robust.
One of the best ways to help ensure that betas don’t run into situations like we are discussing here is to help test the dev builds and help test the third-party packages you use with the dev builds. 