[TxMt Plugins] TmCodeBrowser as plugin problems

[Allan Odgaard]

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)