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
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
but doesn’t support the OS and therefore it crashes in the
without issue, or if there are other crashes.
It crashes during load with `EXC_BAD_ACCESS`, here’s an excerpt from
io.emmet.EmmetTextmate +[Emmet sharedInstance] + 47
io.emmet.EmmetTextmate -[Emmet init] + 87
io.emmet.EmmetTextmate -[Emmet setupJSContext] + 233
enumerateObjectsWithOptions:usingBlock:] + 217
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
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
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”.