Recently I saw a few bugs for text package with comments like
"this fixed caused regression ....". I worked on text package for a
while and I can just confirm that it _is_ very fragile, the order of calls
must be kept otherwise something will fail, but it is not known which
these calls are, etc. Unfortunately I cannot provide more details,
just this general feeling. I would consider some refactorings/cleanup
in this area if the resources are available. Let me know if I could help
reassigne to David K., new owner of editor
Making this issue umbrella for potential cleanup/redesign of text
package. This is just organisational effort - no resources committed
at the moment. I would like to make this issue dependant on several
other issues which should be considered as part of the cleanup.
A minor thought re performance - I've been recently writing a tutorial that covers
DataEditorSupport has to be the strangest class in NetBeans, possibly anywhere - it
implements a bunch of interfaces, but doesn't...and the subclasser has to figure that out.
But we'll leave that alone for now...
DataEditorSupport does everything through its <code>getEnv()</code> method.
CloneableEditorSupport.Env requires at least one, typically two (if you are lazy and split
PCLs and VetoablePCLs) listener lists. It would all be very nice if it were created on
demand, but the CloneableEditorSupport.Env must be passed to DataEditorSupport's
superclass constructor - which means the whole thing must be created just to see if a file
could be edited, when it will only be used if a user actually opens it in the editor.
I'm not sure we'd get a lot of gain out of making DataEditorSupport a little more lazy - I
don't know who's using it - but it might be worth measuring - you shouldn't need to
allocate all that stuff just to satisfy a request for OpenCookie or EditCookie - right now it
looks like you do unless you implement everything yourself.
Reassigning to new module owner mslama.