From: Peter Graves <peter@ar...> - 2003-01-08 15:27:09
This morning's snapshot is up:
http://armedbear.org/j-jar.zip (just j.jar)
This snapshot will be released shortly as 0.18.0, unless something
comes up in the meantime (and there ain't much meantime left).
The behavior of the undocumented and experimental (but very useful)
p4AutoEdit option has changed slightly in this snapshot.
To activate this option, you need to add this line to ~/.j/prefs:
p4AutoEdit = true
Then, when you start to edit a file that is read only on disk, j will
try to check it out ("p4 edit <filename>") using the Perforce command
line client, p4, which must be in your PATH. (Obviously, if you don't
use Perforce, this whole discussion is of no use to you. Move on.)
If the "p4 edit" command succeeds unconditionally (for want of a better
term), j puts an unobtrusive message in the status bar ("File opened
for edit"), the editing operation that was initiated on the read-only
file succeeds, and life goes on.
The change in this snapshot has to do with the case where "p4 edit"
succeeds, but there are complications. The most likely complication is
that the file in question is also open for edit by another user.
Previous versions of j did not recognize this situation correctly,
mistaking these complications for outright failure, and the editing
operation would fail with the message "Buffer is read only". But then,
the next time the sidebar was refreshed, you'd see that the file was
Starting with this snapshot, j is a bit more optimistic about things,
and no longer assumes that "yes and by the way..." means "no". Now,
when you try to edit a file that's open for edit by another user, the
edit will succeed (provided, of course, that "p4 edit" succeeds), but
you'll also get a transient output buffer containing the output of the
"p4 edit" command, so you can see exactly what's going on. (If there
are no complications, you'll just get the unobtrusive message in the
status bar and no transient output buffer, as before.)
p4AutoEdit also comes into play if you're doing replaceInFiles. If
you're doing a multiple-file replace operation that involves files
under Perforce control, j will try to check them out on the fly, if
need be, to perform the replacements. In this situation, which is
already a bit outlandish, it would be even more outlandish to present a
transient output buffer for each file that didn't check out cleanly. Of
course there are better ways to deal with these warnings (they could be
inserted in the transient output buffer that replaceInFiles itself
uses, for example), but this sort of thing falls in the category of
tricky to code and hard to test, so I thought it best not to make any
change in this area on the morning of an official release. So you'll
just get an error message if "p4 edit" doesn't succeed cleanly during
replaceInFiles, and replaceInFiles won't work quite right in this
situation. The workaround is to check the files out first. This is the
way replaceInFiles has worked for a long time.
Thanks for your support.