From: Peter Graves <peter@ar...> - 2003-05-10 17:50:51
This morning's development snapshot (j 0.18.1.10, lisp 0.0.0.29) is up:
http://armedbear.org/j-jar.zip (just j.jar)
Syntax highlighting in diff mode now handles diff -c and diff --normal
correctly (or at least more correctly than before).
For best results, use diff -u. To make this easy, if you do Alt X,
"diff file1 file2", j now inserts "-u" into the command string for you,
making it "diff -u file1 file2". This is only done if you do not
specify any command line switches of your own; strings like "diff -b
file1 file2" or "diff --normal file1 file2" are passed through without
Man buffers are now transient, so you can use Esc to close them.
Bug #733590 is fixed:
If I do a replace in files command with confirmation and J brings
up a list of say 10 files that contain the string that needs to be
replaced. I start confirming the replacements in each file. If J
gets to file 3 and it is read-only, it announces to me that the
file is not writeable and gives me the option of continuing. If I
choose to continue, it will bring up file 4 and let me confirm the
changes there, and that's it. It will never proceed past one file
after the read-only file, no matter how many more are in the list.
For the record, it turns out that this bug wasn't really related to
A while back, code was added to j that essentially called unsplitWindow
if, after killing a buffer, both windows ended up looking at exactly
the same thing, which in most such cases is the right thing to do.
The replaceInFiles code, which has always somewhat resembled a pig's
breakfast, was calling Editor.killBuffer(), which might unsplit the
window in the aforementioned circumstances, rather than the lower-level
Buffer.kill(), which does not, to close the buffer used for the
replacement operation when "Confirm changes" was selected. Unsplitting
the window destroyed the editor that was in use, causing a subsequent
call to getGraphics() to return null, which led to an NPE in the
display code, which aborted the replaceInFiles operation. The fact that
all of this was happening in two threads with liberal use of
SwingUtilities.invokeAndWait() helped to muddy the waters and make it
hard to come up with an exactly reproducible scenario.
Anyway, as mentioned, the bug is fixed, and the code has been cleaned
up a bit. The most notable cleanup is that once the files involved have
been identified by what amounts to findInFiles in a background thread,
the actual replacements are done in the foreground thread, which makes
the control flow a bit easier to follow.
This code could still use another cleanup pass, but I don't have the
stomach for it at the moment.
Finally, indentation in Java mode should now work correctly with the
"gnu" indentation style (which is used, for example, in the GNU
Classpath project source).
Thanks for your support.