From: Peter Graves <peter@ar...> - 2002-09-14 20:01:41
This morning's 0.16.4+ snapshot is up:
http://armedbear.org/j.zip (source and documentation)
http://armedbear.org/j-jar.zip (just j.jar)
For a while now, findInFiles has worked by sending its output to a
transient output buffer that gets displayed in the other window of the
current frame (splitting the current window if necessary).
Starting with this snapshot, some new behavior has been added to
facilitate navigation in this situation.
At the moment, the new behavior only works if:
1. the last search in the current editor was findInFiles
2. the findInFiles output buffer is in the other window of the
current frame (which is the default situation)
If these conditions are met, j now tries to make the location of
the caret in the findInFiles output buffer follow along with the
commands findNext (mapped by default to Ctrl G and F3) and findPrev
(mapped by default to Ctrl H and Shift F3) when these commands are
carried out in the editable buffer in the other window.
Currently the algorithm to do this is not very smart, so things will
very likely get out of sync if you make significant changes to the
editable buffer as you go along. This deficiency is basically
harmless, since that was the old behavior at all times.
In addition (and this is the real point), once you get to the end (or
beginning) of the current buffer with findNext/findPrev, the next
invocation of findNext/findPrev, instead of failing the search, will
continue on with the next (or previous) file in the findInFiles output
This is extremely useful if you're looking for occurrences of a
particular string in a big set of files in order to make changes that
are more complicated than can be accomplished by a simple multifile
Right now, this behavior is the default (if the aforementioned
conditions are met), and the only way to turn it off (and force
findNext/findPrev to fail at the end or beginning of the current
buffer) is to use Escape to get rid of the findInFiles output buffer.
This is not such a bad thing, since you can always get it back with
Note that this trick only happens when both the editable buffer you're
doing findNext/findPrev in -and- the findInFiles output buffer (in the
other window) are in plain view, and only when findInFiles is the
current search (i.e. you haven't done any other search since doing
In other news, the p4AutoEdit option now works seamlessly with
replaceInFiles, a combination that's definitely not for the faint of
Thanks for your support.