|
You are right about the design. TextEditor didn't
originally allow subclassing. However, it was subclassed in the Jave editor
example and other such code, so I requested that they remove the restriction,
which they did for 2.0. So it's my fault. ;-} For the 2.1 release, a number
of features were migrated from JDT to text and added to TextEditor (instead of,
say, AbstractTextEditor). So it's now virtually necessary to use it. Imagine my
chagrin when I discovered I couldn't because there was no way for a subclass to
disable/replace the default encoding support. I requested this very late in the
2.1 cycle and was very pleased to see it go in. It does seem to be the "Eclipse
way" to address today's requirements today and refactor as needed tomorrow.
Works for me.
Bob
----- Original Message -----
Sent: Wednesday, April 23, 2003 2:31
PM
Subject: RE: Think big (RE: [eclipse-dev]
Re: What's happening after 2.1?
I'd
like to second this. JDT's editor has so many great features that
people want to emulate them in their own editors. But it's really hard to do
that. Sometimes they just copy the JDT editor code and modify it, but then the
JDT moves on (witness the CDT editor). Some bits and pieces have made their
way into TextEditor (like annotations) which is welcome but it's not enough.
Also I get the impression TextEditor wasn't meant to be subclassed like it
is.
One way to overcome this problem and enable us to experiment with new
innovative code editing technologies might be to refactor the current JDT
editor support away from the current editor so it could be added to *any*
editor that is embedded inside Eclipse. This would enable people to
keep using (and developing if they like) the current code editor while we
experiment with other, more experimental and innovative
designs.
| 