> > There are still ArrayOutOfBoundsExceptions being thrown in what
> looks like
> > the folding code. When I get back to testing (maybe with your
> next build),
> > I'll look at this more closely.
> Try checking out the most recent code.
> > Well, all I can tell you is that system memory usage jumped
> from about 30MB
> > to 77MB when I left 3.2.2 running overnight with a block caret.
> My bulldog
> > aszures me that he was not doing any late-night editing.
> Maybe this problem is caused by something else, for instance the global
> options dialog being opened and closed.
The memory buildup I described occurred with the application open but
completely inactive: no user input at all.
I built jEdit 4.0 from CVS following a series of check-ins noted on the CVS
mailing list, the last being dated Sunday October 28, 2001 @ 21:39 (that is
the server's time, UTC -0800).
The first test run occurred on Win2K, JDK 1.4 beta2, with the splash screen
turned off, and with any plugins throwing exceptions at startup removed.
JDiffPlugin was also removed because of a VerifyError being thrown on tghe
opening of buffers (even when the plugin was not active). I had
the -settings command option point to my existing user settings directory.
Anyone doing testing on JDK 1.4 under a Windows OS should remember to
deactivate the MouseWheel plugin that works under JDK 1.3.x. Renaming the
.jar and .dll files temporarily is all you need to do.
I loaded once, closed all open buffers, then exited and loaded again, so
that on the second run, only an "Untitled-1" buffer was presented. Both
times the application loaded faster than jEdit 3.2.2. This may be because
of the lower numbers of plugins.
After typing several test lines and scrolling, I found the same screen
painting problem found using jEdit 3.2.2 with JDK 1.4: when using a block
cursor, the portion of the text area below the current line is painted in
the wrong colors and is unreadable. This does not occur when the block
cursor feature is turned off. Toggling the blinking cursor feature does not
affect screen painting.
With the block cursor turned off, I was able to enter text and navigate
through the new buffer without any observed problems.
One very useful advantage of this installation is that the leading between
lines of text is reduced for a more compact display. I think this is an
improvement built into JDK 1.4.
I was also able to load several files and navigate around their buffers
The color coding of files in the VFS Browser display is very helpful. I can
envision platform-dependent extensions of this feature to deal with
executable files (at least on Windows, where specific extensions are used)
and perhaps other file types.
Some of the vertical docking component button labels are cut off on the
right side of the text. You might be able to solve this quickly by adding a
space character to the string that is painted in the button. It would
improve the appearance of all of the buttons, as they seem slightly
off-center to the right. Probably a small modification to the drawing code
would accomplish this as well.
When Global Options dialog is activated, the JCompilerOptionPaneCompiler
class throws a NoSuchMethodError because of an attempted call to
When the HartMath plugin is activated by clicking on the corresponding
docking component button, it throws the following error and does not become
[error] EditBus: java.lang.VerifyError: (class: HartMathDockable, method:
insertInput signature: (Ljava/lang/String;)V) Incompatible object argument
for function call
[error] EditBus: at HartMathPlugin.handleMessage(HartMathPlugin.java:82)
[error] EditBus: at org.gjt.sp.jedit.EditBus.send(Unknown Source)
[error] EditBus: at
[error] EditBus: at
[error] EditBus: at
I then closed and reopened the application. The last file on the screen
when the application exited loaded and was painted properly. However, when
I switched to another buffer that was loaded at startup, I saw only a single
line of text. It consisted of the the first line of text in the file plus
the string "[48 lines]" at the end. After attempting to navigate by
pressing the down arrow, the text area showed only a line "50" in the gutter
(2 more than the number of lines reported) with an otherwise empty text
area. I was unable to perform any further buffer navigation. However, the
display corrected itself once I selected "View>Folding>Expand All Folds".
When switching from JDK 1.4 to JDK 1.3.1, I found two major differences: (1)
on JDK 1.3.1, the block caret does not create a painting problem in the text
area below the current line, (2) the vertical labels for docking component
button are misaligned vertically and have the upper half of the text
clipped. These issues have already been reported. The forced folding of
buffers described in the preceding paragraph also occurred under JDK 1.3.1.
I did not track memory consumption in this round of tests.
I would say that once you deal with the GUI issues on either JDK 1.3.1 or
1.4 (so the GUI would be solid on at least one version), fix the splash
screen, fix the "forced folding", and have a set of recompiled plugins, you
should be ready to go with 4.0pre1.
It might be better to target JDK 1.3.1 for the first development release
because (according to the jEdit Community survey), most users are running
it, and because we may see another beta of JDK 1.4 that deals with the block
caret problem for you. JDK 1.4 also seems to have introduced a number of
new bugs of various types on the Windows platform. I would not yet consider
it a stable release for complex Swing applications.
Naturally, you will get more and better feedback once you are out of CVS. If
you want to hold off on 4.0pre1 for more tinkering, and you would like me to
post a daily build of 4.0 on jEdit Community (without help files for now, as
I don't have the XML build installation configured yet), let me know.