"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."
OK here is one example of why detaching the view the editor presents from the file contents would be useful There are others in my head, this one is well known, and moreover, others that have yet to be thought of by anyone will come into existence.
Take the instance of a UML editor, and just to keep it simple, a class diagram of a single class. That class diagram is a view of the the text-based java file. The one's I've seen basically re-present the same information in the java file, albeit with some things left out and the rest rearranged in little boxes. Now, you can create this little class diagram in a lot of ways, but the easiest, most natural, and most object oriented is to just render the view of that file java differently. If I have to create a whole new file type from an existing file type that already has everything I want, well that has a bad smell.
The thing is, if the diagram is still an editor, then all Good Things that IntelliJ provides editors of java files still hold in the diagram view. Code insight. The ability to initiate and see the results of refactoring. Syntax coloring. Etc etc. What do you care what character I tell the Editor its caret is at when the user clicks the mouse or presses a key at THIS place on the screen? All you need to know is the logical place in the file, and I'll take care of the view. As for bookmarks and error stripes, THAT editor represents them differently, or not at all, or whatever works.
So if internally the painting logic of the editor is tied to those methods, then that's a good thing, as long as they only go through those methods and not around them. Then implementors can create novel ways of looking at code just by overriding a small group of methods of Editor.
Here's another one. Annotations. If you read Gosling's book on the Java language, he explicitly warns the readers that Annotations can become burdensome if they are overused because they clutter things up. But he's wrong- that's not the problem. His statement represents just a completely pedestrian failure of imagination on the part of an otherwise brilliant mind.
The problem of clutter is a UI problem. UI problems like that are solved by editors and how they render information. The fact that annotations have to be in a certain place in the stream of characters of a java file according to the java spec can mean nothing to us as creators of tools. What we throw to the compiler is whatever it wants, OK. Annotations precede the annotated, fine. But what we present to the editor of a java file is ... whatever is useful in whatever way works.
I could easily create a annotations UI that would let you pile a thousand annotations on a method if you wanted to and in your capacity as an editor to that file you'd never know or have to care unless you wanted to.
But in order to do that, I need to be able to create a view of the java file that supports that and that means overriding Editor. There is no reason that just because the java compiler expects to see annotations in a certain place in the character stream, that I have to pass that on as a visual reality to the viewer / editor of the file. The idea that the editor exactly represents the characters of a file as the compiler demands them to be is over and done.
I need the power of elision and and a bunch of other things that go beyond the little fold-up plus sign that Intellij offers (and which are very nice). I can make those things for myself if I can control the rendering of the editor.
Look, the rendering of the information that is presented by Editor needs to be opened up. If you don't do it, your (free) competition will, and the New Good Ideas will be there, and not here. And believe me, it's not just UML diagrams and the presentation of annotations that hang in the balance here. That's the least of it - trust me.
The separation of model from view is staple fare in programming. It doesn't need any big justification from me; it's a winner and many wonderful things do flow from it and will continue to flow from it. The Intellij team has a long (in internet time) and distinguished record of being the first to invent really Useful Things . That's just the track record so far. The companies who copied Intellij were just too hide-bound and top-heavy and had too much of a "we know it all" ish attitude to innovate anything. They've since woken up. Don't now become like them. Don't think you know the landscape. Remember what Proust said- The real voyage of discovery consists not in seeking new landscapes, but in having new eyes.
The difference between the editors of today and what we could have is like the difference between a green screen and what we have now. It just is. But you need to get away from the tyranny of the compiler.
You need to open this up and you need to make available everything that causes changes to the underlying document with an API that is semantically rich, meaning, it represents what happened at a semantic level (anonymous class extracted to inner class...) so plug-in implementors can react the semantics of events and not just generic "changes" to the underlying document.
So why not open Editor up for extension? What is the roadblock?
Message was edited by: