@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 TextMate.app/Contents/PlugIns/Dialog.tmplugin
TextMate.app/Contents/PlugIns/Dialog.tmplugin: valid on disk
TextMate.app/Contents/PlugIns/Dialog.tmplugin: satisfies its Designated Requirement

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

% spctl -a -v TextMate.app
TextMate.app: 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