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”.