On 14 Jul 2016, at 22:39, Graham Heath wrote:

This might not seem like a big deal, but I love Emmet, and so do many of my

web-dev cohorts.

I didn’t know this was actually working for anybody.

I’m not sure if this

is because its crashing in use, or if its because the plugin was installed,

but doesn’t support the OS and therefore it crashes in the background

without issue, or if there are other crashes.

It crashes during load with EXC_BAD_ACCESS, here’s an excerpt from the crash:

io.emmet.EmmetTextmate     +[Emmet sharedInstance] + 47
io.emmet.EmmetTextmate     -[Emmet init] + 87
io.emmet.EmmetTextmate     -[Emmet setupJSContext] + 233
com.apple.CoreFoundation   -[__NSArrayM enumerateObjectsWithOptions:usingBlock:] + 217
⋮
com.apple.JavaScriptCore   WTFCrash + 62

Is there any way to know if this custom built plugin is causing crash

reports, or is it just the original?

I extracted the UUID from the updated binary and searched for “load plug-in” crash reports with this UUID, and did not find any.

So it does not appear that this version has caused any crashes.

What I’ve discovered so far is that the blacklisting uses "contains" rather

than "equals" so updating the Bundle identifier to

'io.emmet.EmmetTextmate2' was not enough

You tested this?

The blacklist is an array, and the check is if the array contains the bundle identifier. So it should have worked.

It’s worth mentioning that the blacklist can be changed by updating user defaults, so anyone with the updated/working Emmet plug-in can also run:

defaults write com.macromates.TextMate.preview disabledPlugIns -array

But it would be best to give the working plug-in a new bundle identifier and have people use that instead. I can add a release notes entry about this, if there is something “official”.