From gerti-textmate at bitart.com Wed Nov 2 21:16:44 2005 From: gerti-textmate at bitart.com (Gerd Knops) Date: Wed, 2 Nov 2005 15:16:44 -0600 Subject: [TxMt Plugins] TmCodeBrowser as plugin problems Message-ID: <8CF3A4DE-8D81-4DD7-A1F6-4C49EE103EEA@bitart.com> Hi Allan, I am trying to get TmCodeBrowser.tmplugin out, as the current version is not compatible with the recent OS X update. I run into a problem though: The plugin is loaded to late, specifically after any documents on the command line or any projects that are auto-reloaded are instantiated. That causes my hacks to fail. I'd rather not go back to the old 'InputManagers' hack, which seems to work probably because it loads earlier. So is there any way you could load the plugins earlier? Or alternatively (or in addition) provide enough for me to not need to resort to hacks at all. All TmCodeBrowser would need is some notifications: - when the current 'front' document changes (my hacks hook into OakProjectController's setCurrentDocument: and windowDidChangeKey: methods, as well as into OakDocumentController's setTextDocument: method) - after the current 'front' document was saved (OakDocument's writeToFile:) - and possibly when the current 'front' document's language changed (I don't currently catch those, but would need it for my special- cased Objective-C support) The notification object should make (maybe via a protocol) available: - The documents full path/filename [OakDocument filename] - The documents languageUUID [OakTextView languageChoiceForCurrentFile] - The name of a language [OakTextView languageForUUID:] Gerd From throw-away-1 at macromates.com Thu Nov 3 11:26:45 2005 From: throw-away-1 at macromates.com (Allan Odgaard) Date: Thu, 3 Nov 2005 12:26:45 +0100 Subject: [TxMt Plugins] TmCodeBrowser as plugin problems In-Reply-To: <8CF3A4DE-8D81-4DD7-A1F6-4C49EE103EEA@bitart.com> References: <8CF3A4DE-8D81-4DD7-A1F6-4C49EE103EEA@bitart.com> Message-ID: On 02/11/2005, at 22.16, Gerd Knops wrote: > [...] The plugin is loaded to late, specifically after any > documents on the command line or any projects that are auto- > reloaded are instantiated [...] So is there any way you could load > the plugins earlier? Sure -- I've moved the plug-in loading to before loading documents. > Or alternatively (or in addition) provide enough for me to not need > to resort to hacks at all. All TmCodeBrowser would need is some > notifications: > > - when the current 'front' document changes (my hacks hook into > OakProjectController's setCurrentDocument: and windowDidChangeKey: > methods, as well as into OakDocumentController's setTextDocument: > method) Instead of setCurrentDocument: and setTextDocument: I'd suggest overloading NSWindow's setRepresentedFilename: -- I use this with bindings, so it'll be called more than it needs to (i.e. check existing value before you start to recache stuff or similar), but it should be sufficient to give you notifications about when the user switches tab and when files are loaded, and when they are saved to a new location (I just tested it in the Clock Example PlugIn). As for when it gets saved, this will trigger a setDocumentEdited: on NSWindow. Of course this is just provisional, until I provide a more official way to get these callbacks (I'm currently piecing together a more full featured API for all of this, incl. SCM support and will also make the HTML preview a plug-in, but it might be a week or so before I provide it -- actually, I may do 1.1 in 7-10 days and then offer the plug-in API as the first thing in the 1.2 builds (which of course should follow shortly after)). > - and possibly when the current 'front' document's language changed > (I don't currently catch those, but would need it for my special- > cased Objective-C support) I can fire a notification for this (in next build). I'll provide a user dictionary with: language name -- this is really just for display purposes scope name -- this is what I'd suggest you use to match file types, since it also captures inheritance, like ?source.ruby.rails? => Ruby source path -- most likely an NSURL to make it safe for the future window -- I only want to put that in the dictionary if you need it, since I want documents associated with an interface that provide the necessary windows related methods (like addCellToStatusBar: etc.), and not a concrete object (especially not an NSWindow) From throw-away-1 at macromates.com Thu Nov 3 12:58:59 2005 From: throw-away-1 at macromates.com (Allan Odgaard) Date: Thu, 3 Nov 2005 13:58:59 +0100 Subject: [TxMt Plugins] TmCodeBrowser as plugin problems In-Reply-To: References: <8CF3A4DE-8D81-4DD7-A1F6-4C49EE103EEA@bitart.com> Message-ID: <817441CA-1D46-4BAF-99C5-2EFA9619CD66@macromates.com> On 03/11/2005, at 12.26, Allan Odgaard wrote: > I can fire a notification for this (in next build). [...] And here are the constants: NSString* TMDocumentLanguageDidChange = @"TMDocumentLanguageDidChange"; The name of the actual notification. The user info contains: NSString* TMDocumentURL = @"TMDocumentURL"; The (file) URL of the document. This key is not present for untitled documents. NSString* TMDocumentLanguageName = @"TMDocumentLanguageName"; The display name of the language (e.g. ?Objective-C?). NSString* TMDocumentLanguageScope = @"TMDocumentLanguageScope"; The root scope for that language (e.g. ?source.objc?). NSString* TMDocumentWindow = @"TMDocumentWindow"; The NSWindow object which holds the document. This is available starting with r687 (which is online). From throw-away-1 at macromates.com Sat Nov 5 05:14:06 2005 From: throw-away-1 at macromates.com (Allan Odgaard) Date: Sat, 5 Nov 2005 06:14:06 +0100 Subject: [TxMt Plugins] Restarting TM after install & auto update of plug-ins Message-ID: I was thinking of introducing a key in the plug-ins Info.plist which would tell TM that the plug-in requires TM to be restarted after install. Probably I should always (prompt the user for) restart on update, seeing how the old version of the plug-in can't be unloaded. In addition I could also allow the plug-in to specify an URL that contains (info about) latest version, so TextMate can include plug- ins in version checking. This I'm unlikely to get done before 1.1 final, but stuff to think about. From gerti at bitart.com Sat Nov 5 05:41:07 2005 From: gerti at bitart.com (Gerd Knops) Date: Fri, 4 Nov 2005 23:41:07 -0600 Subject: [TxMt Plugins] Restarting TM after install & auto update of plug-ins In-Reply-To: References: Message-ID: <1A4AAE1E-8F2C-49AD-9870-2BCD87CCE36F@bitart.com> On Nov 4, 2005, at 23:14, Allan Odgaard wrote: > I was thinking of introducing a key in the plug-ins Info.plist > which would tell TM that the plug-in requires TM to be restarted > after install. > > Probably I should always (prompt the user for) restart on update, > seeing how the old version of the plug-in can't be unloaded. > While it *IS* possible to unload classes, a lot of things need to line up for that to work. So my vote would be to always prompt for a restart. Also the updated plugin should NOT be loaded at all after the update, just leave the old one running. Anything else might cause all kinds of unforeseen behavior. > In addition I could also allow the plug-in to specify an URL that > contains (info about) latest version, so TextMate can include plug- > ins in version checking. This I'm unlikely to get done before 1.1 > final, but stuff to think about. I was thinking about something like that, that would save me the work. Not sure how you do it with TM, but my guess is we need an URL which returns the current version and where to find it. And obviously you will have to decree a standardized packaging format. Gerd