Since there's no way to re-mark a thread as a question and my new post was way at the bottom of the old one where perhaps no-one would notice it, I popped this new question into a new thread
OK this is a lifecycle question I think. I am asking about the lifecycle fo Editors. Where they come from with respect to the lifecycle of applications projects and documents and how I can inject myself into that lifecycle reliably.
OK so.. I am having trouble understanding what I need to do to make sure my editor implementation is used anywhere a reference to an editor method is invoked by any code whether it's in the OpenAPI or not.
To do that, I am not sure what needs to be done or even if it's practical to try. What must be true is that at sometime when a project is loaded and after that when a Document is displayed, an Editor (an com.intellij.openapi.editor.impl.EditorImpl, though I don't see that package in the OpenAPI, that's how it reports it's own class via getClass())
gets created. That's really all I am sure of.
So I want all such editor creation activity to pass through me somehow so I can (somehow) arrange for myEditorImpl to be used. MyEditorImpl is just a pass-through wrapper that overrides a small subset of methods.
For instance, here's some code from Sascha Weinreuter's xpath plugin XPathView
FileEditorManager fem = FileEditorManager.getInstance(project);
editor = fem.getSelectedTextEditor();
the getInstance() implies a singleton so perhaps I should subclass THAT first to bring back and instance of MyEditorImpl. Here are the problems.
No knowledge of when the default FileEditorManager is created means that by the time I (somehow) replace it with my own version, internally to IntelliJ, it could have already been used by classes I know nothing about to retrieve and gain references to (default) Editors which are stored and used throughout the lifetime of the program. That means, essentially, I show up to the party, but too late.
Moreover, even if there are no problems with that today, because there's no formally sanctioned means of replacing FileEditorManager, the above situation could come to be programmed by others at any point in the future.
No guarantee that FileEditorManager is the one and only way Editors come into existence. Even in the OpenAPI, there are any number of classes that return an Editor- including some com.intellij.debugger, com.intellij.ide.structureView and a bunch of others. Still other things I've seen are serialized class names which are used to recreate instances when the [program is relaunched etc. etc.
So there's really no way to analytically come to any hard conclusions about where and when Editors are created so that their behavior can be overridden reliably. FWIW , I am interested in TextEditors which appear to be related to Editor via composition (TextEditor.getEditor()).
It seems as if for the reasons above, that Editor provides a lot of read-only information-i.e. can't be subclassed or used in a delegation scheme.
That's why I am hoping that someone in IntelliJ just knows and maybe even tell me there are plans going forward to expose TextEditor in such a way as it supports having it's behavior-appearance being overridden.
Is there some point in the loading of a project or application where I can get code executed that would ensure this, like inserting a class definition in as the value to a key ala Swing UIDefaults? Or do I have to so it each time a java class is loaded through double clicking it in the tree or creating it.
I will put in a request to KIRA to expose the Editor for subclassing.
I know it's a high level how-does-it-all-go-together type question, but that's the reason I can't figure it out . Perhaps the applications and projects are not structured to support this idea.
End of a somewhat rambling question.