Extending Editor (redux)
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.
Please sign in to leave a comment.
Hello softwarevisualization,
There is no way to plug a custom implementation as a replacement for EditorImpl,
and we do not plan to provide such a way. The correct course of action is
to extend, rather than replace, EditorImpl, but I can't provide any more
details without knowing what you would like to achieve.
--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
Fair enough! Bad news can still be solid information! Thanks Dmitry!
Dmitry,
FWIW, these are the ones I want to override. I know Swing's JEditorPane (well Document I think it is) will let you do this, in case the the EditorImpl is using JEditorPane under the hood.
All these methods are from the interface Editor.
java.awt.Point visualPositionToXY(VisualPosition visible)
Maps a visual position in the editor to pixel coordinates.
LogicalPosition visualToLogicalPosition(VisualPosition visiblePos)
Maps a visual position in the editor (with folded lines and columns not included in the line and column count) to a logical position (the line and column ignoring folding).
LogicalPosition xyToLogicalPosition(java.awt.Point p)
Maps the pixel coordinates in the editor to a logical position.
VisualPosition xyToVisualPosition(java.awt.Point p)
Maps the pixel coordinates in the editor to a visual position.
java.awt.Point logicalPositionToXY(LogicalPosition pos)
Maps a logical position in the editor to pixel coordinates.
VisualPosition logicalToVisualPosition(LogicalPosition logicalPos)
Maps a logical position in the editor (the line and column ignoring folding) to a visual position (with folded lines and columns not included in the line and column count).
LogicalPosition offsetToLogicalPosition(int offset)
Maps an offset in the document to a logical position.
VisualPosition offsetToVisualPosition(int offset)
Maps an offset in the document to a visual position.
Yes extend, that's what is wanted. In fact, just exactly those methods I mentioned below (or above). Those are the methods whose default behavior needs to be extended in a subclass.
Of course, extended can mean two different things here- one is "to extend the general usefulness" by , obviously, writing some plugin as many have already done and the other is "to extend in the technical sense" , which means subclass a specific class, in this case EditorImpl. The second is what is wanted but apparently not possible at this time.
Message was edited by:
softwarevisualization
Hello softwarevisualization,
No, EditorImpl does not use JEditorPane, and no, these methods cannot be
overridden by a plugin. In fact I don't understand what you want to achieve
by overriding only those methods because they are coupled with the painting
logic of the editor, and the users would see very weird results if your implementations
returned some values that don't match what they see on screen.
--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
LOL well you could certainly go wrong with your hands on those levers, you're more than right there. It's a fair question and it deserves a fair answer. Remember that usually the ordinal position of the characters in the data structure in memory, a char array say, is fully detached and detachable from their ordinal position on screen, and even if that's not explicitly realized in the API, it's not far away either. As far as the painting logic goes, that's the point. MyEditorImpl would be taking that over, through delegation mostly, to Intellij's and topping it with a little custom logic, so you're right again. There isn't time now to make the argument and besides, what's an argument without a demo anyway, eh? So for now call this question answered and note that a convincing case for this functionality has yet to be made.
A path without obstacles probably leads nowhere.
Message was edited by:
softwarevisualization