Extending Editor justification

: "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:
softwarevisualization

5 comments
Comment actions Permalink

Hello softwarevisualization,

It actually helps to be familiar with the architecture of IntelliJ IDEA before
criticizing it. IntelliJ IDEA does have a quite clean model/view separation
in this part of the architecture. The model is Document, the view is Editor,
and the different actions are Controller.

Therefore, providing an alternative view of a Java file does not require
replacing EditorImpl. All you need to do is to have a FileEditorProvider
in your plugin, and to provide a FileEditor which represents the Java file
in whatever way you like. And if you return correct data through the DataProvider
API, all (or most) of the editor actions could be made to work in your editor
implementation. Of course, if you want, for example, error highlighting,
you'll need to implement your own way of rendering the information you get
from the model (Document.getMarkupModel()). But all of this is perfectly
doable with our current architecture.

<Dmitry said>:
"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 said>:
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 what 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
of 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
si no reason that jsut because the java compiler expects to see
annotations in a certain place in the character stream, that I have
to pass that visual reality on 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.

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 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. 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.

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?

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

I did actually ask about those classes you now mention and overriding Editor for the purpose of extending its functionality generally, and suggested a lot of approaches, wrapping the existing editorImpl being just one of them. It's all here http://intellij.net/forums/thread.jspa?threadID=268041&tstart=0 and here http://intellij.net/forums/thread.jspa?threadID=272542&tstart=0

As far as criticism goes, no one is criticizing anything. You asked me what the point of wanting to override those methods was and so I told you. You definitely left the impression that you didn't see any point in it and it wasn't supported.

I'm sure what you say about FileEditor is true since you have special access to things I don't. Of course it's not (logically) necessarily true, so really no matter how much I know about the architecture I'm not going to be able to answer all of my own questions.

The majority of the API is totally undocumented - not a criticism just a fact. That makes things harder than they otherwise would be.

In this case, there are six classes spread across several packages that bring back a FileEditor all of which needs to bring back my custom FileEditor for things to work.
Plugin writers might have the task of manually arranging that their FileEditor be the one returned.

I gather from your post they don't, but they can't know that apriori. I did actually bring up the question of the singleton FileEditorManager bringing back a FileEditor and if it was necessary to worry about FielEditorManager being invoked before the custom FileEditor had been defined. That was my lifecycle question. http://intellij.net/forums/thread.jspa?threadID=272542&tstart=0

Well if there's something I can do to be clearer in my questions or communication just let me know. I once had gerbil that ate it's own kids the day they were born. I thought that was weird, unhelpful and deeply counterproductive to the assumed purpose. Having the online resource tell me I ought to understand the undocumented architecture better before I ask questions or make comments sort of feels the same way to me.

0
Comment actions Permalink

Hello softwarevisualization,

In this case, there are six classes spread across several packages
that bring back a FileEditor all of which needs to bring back my
custom FileEditor for things to work. Plugin writers might have the
task of manually arranging that their FileEditor be the one returned.


A plugin developer only needs to provide an implementation of one interface:
com.intellij.openapi.fileEditor.FileEditorProvider

It's actually documented and used in many open-source plugins. Note that
implementing this interface will not replace the standard text editor for
Java files - rather, your editor will be shown in another tab next to the
standard editor, in the same way as diagram tabs are shown for Spring configuration
files, for example.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Hello softwarevisualization,

As far as criticism goes, no one is criticizing anything. You asked me
what the point of wanting to override those methods was and so I told
you. You definitely left the impression that you didn't see any point
in it and it wasn't supported.


If you ask very specific questions like "how can I override this method?",
I can only provide very specific answers, which in many cases amount to "no,
this can't be done". If you describe the task you're trying to accomplish,
I can point you to the most appropriate APIs to be used for solving the task,
and it's much easier for me to provide actually useful answers.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Thanks Dmitry, I'll try to be clearer. Best wishes.

0

Please sign in to leave a comment.