Can someone perhaps explain why does Emmet have to be a plugin?
I'm not an expert, but Emmet in its core is JS library, and plugin seems a bit of overkill.
Besides, it's menu is placed at the top level, which, IMHO is unnecessary since it only covers HTML/CSS scope.
My approach is far from perfect, but I think it's simpler and easier to maintain,


On Sat, Jul 13, 2019 at 5:41 PM Graham Heath <> wrote:

@feek; Fascinating, thats something to be excited about!

@Zdenko; Thanks, thats amazing :)

@allan; I'm running out the door, but if you like I'll put a formal pr together (if only for review).

To see this error I had to make some changes in the source.

In TMPlugInController, line 90 (original);

if([bundle load])


NSError *bundleLoadError;

if([bundle loadAndReturnError:&bundleLoadError])

and then down on 104 (original);

NSLog(@"Failed to load plug-in: %@, path %@", name ?: identifier, aPath);


NSLog(@"Failed to load plug-in: %@, path %@. Error %@", name ?: identifier, aPath, bundleLoadError);


On 13 Jul 2019, at 3:41, Allan Odgaard wrote:

On 12 Jul 2019, at 22:34, Graham Heath wrote:

I am also seeing the same error for Contents/PlugIns/Dialog2.tmplugin and

Where are you seeing this error?

% codesign -vv valid on disk satisfies its Designated Requirement

And TextMate itself (which embeds the plug-ins) should be notarized:

% spctl -a -v accepted
source=Notarized Developer ID

I tried signing the plugin, but it was already signed.

$ codesign -s "[...]" EmmetTextMate-1.tmplugin

The recent change was the switch to the hardened runtime, this is done by adding --options runtime to codesign.

So try re-sign it with that option.

However, when enabling the hardened runtime the plug-in may need entitlements, for example if it is sending AppleEvents. But lacking entitlements shouldn’t cause a problem loading the plug-in, it will just be a runtime failure from AESend.

textmate mailing list

textmate mailing list