(67/211) 3488 - no caret connecting to an existing file with -reuseview

Yea, this is quite annoying and I'm glad that someone found the way to reproduce.

Note that, when the caret isn't shown, it seems that the Text Area hasn't the focus (You cannot type any character into it) but with arrow keys You can change the current line.

jEdit 4.3.2
SUN Java 1.6.0_22
Windows XP SP3

The difference in the activity log between the buffer hidden (caret gets set correctly) vs the buffer displayed seems to be these two lines:
12:46:05 AM \[AWT-EventQueue-0\] \[debug\] EditBus: BufferChanging\[what=BUFFER_CHANGING,source=org.gjt.sp.jedit.EditPane\[active,global\]\]
12:46:05 AM \[AWT-EventQueue-0\] \[debug\] EditBus: EditPaneUpdate\[what=BUFFER_CHANGED,source=org.gjt.sp.jedit.EditPane\[active,global\]\]

I suspect the visible buffer logic should also execute one or more of these functions

a rough and ready partial workaround is ctrl+2, ctrl+0
The caret is then visible and at the correct location. I have the caret set to blink and it's not blinking.
The textarea has focus and moving the caret restores blinking.

Can reproduce the bug with multiple edit panes in the view so will examine EditPane and calls to it as time permits.

ctrl-l (scroll and center caret) also brings focus back to textarea. I imagine that's a better workaround...

Root Problem:

EditPane.loadCaretInfo() correctly refreshes Buffer.CARET from the buffer when Buffer.CARET_POSITIONED is true.
EditPane.loadCaretInfo() then incorrectly loads Buffer.SCROLL_VERT and Buffer.SCROLL_HORIZ
from CaretInfo instead of from the buffer.
CaretInfo contains the previous or default scroll locations so the caret can end up off the visible screen.

Proposed Solution:

Change EditPane.loadCaretInfo() to also refresh
Buffer.SCROLL_VERT and Buffer.SCROLL_HORIZ from the buffer when Buffer.CARET_POSITIONED is true.
jEdit.gotoMarker should also unset Buffer.SCROLL_HORIZ since -reuseview +line: can change the column
or the EditPane could be scrolled horizontally before a -reuseview request.
This seems like a low risk fix that should work to the same extent that the Buffer.CARET_POSITIONED
signaling mechanism works. It seems to work when a buffer is open in multiple EditPanes and multiple views.

EditServer.handleClient view.requestFocus():

EditServer doesn't run when jEdit first starts.
On Ubuntu 10.04 Netbook remix the jEdit window correctly gets focus on the correct textarea at startup.
On Ubuntu 10.04 Netbook remix with -reuseview the jEdit window does not get focus,
but once you manually or programmatically switch to the jEdit window the correct active text
area does have focus. The EditServer.handleClient view.requestFocus() may be trying to
address this jEdit focus issue or perhaps an issue with multiple jEdit views being open.
After removing the view.requestFocus(); from the last case in EditServer.handleClient, the correct textarea
still gets focus once you get the overall jEdit window to the front.
In testing I didn't come across any cases where view.requestFocus() was needed to set the correct active textarea.

After removing the view.requestFocus(), the screen does not scroll vertically and the vertical scroll
may now be incorrect depending on +line:. The caret may be off the screen as per the root problem.
Hitting a scroll key will now scroll the EditPane and show the cursor.
If you are using the keyboard and not the mouse to scroll, removing the view.requestFocus() makes the problem less severe.
The view.requestFocus() may be simply be trying to compensate for the root scrolling bug in EditPane.loadCaretInfo().

To fix the separate issue of the TipOfTheDay window not getting focus at startup I also disabled EditPane.setBuffer
textArea.requestFocus and haven't noticed any problems with the correct textarea getting focus once you getthe jEdit window
to the foreground. While, this is not part of this fix, it also indicates that there may be unnecessary
requestFocus calls in the jEdit code.

view.requestFocus(); removes the caret both before and after correcting EditPane.loadCaretInfo()
so any fix has to address it.
I put
view.setState(java.awt.Frame.NORMAL);
view.requestFocus();
view.toFront();
into the if (jEdit.getBooleanProperty("server.brokenToFront")) which doesn't run by default in my configuration.

I consider this a somewhat higher risk part of the fix because I'm not sure I completely understand the root issue.

Next Steps

Comments and review are very welcome.

I've attached a partially recompiled jedit.jar for anyone who doesn't have the time or inclination to
rebuild jEdit from scratch. This includes disabling the EditPane.setBuffer textArea.requestFocus as well which is
not included in the diff files in the patch for this defect. The affected classes were recompiled with Java 6 so you will
have to run it under Java 6. I would especially invite people to test on other OSes.

I will create a patch with diff files against the trunk for this bug.

I can't attach the modified jedit.jar as the Uploaded file must be no larger than 256k. If anyone wants to try it, please send me an email via sourceforge.

patch id is 3169868

Googling the problem of moving Java to the front indicates the Swing code required seems to vary by platform and perhaps even by window manager. The code in EditServer that I proposed to put under the if statement is clearly trying to get jEdit to the front programmatically. jEdit is not coming into view on Ubuntu 10.04 netbook remix with the 4.3.2 EditServer code or even the extra code in the trunk for EditServer revision 19324. I don't have a cross platform solution for the moving to front problem and am not able to test on Windows at the moment so I'm retracting the EditServer portion of the fix.

The EditPane and jEdit part of the fix is still valid. It will correct the scroll when -reuseview specifies a file that is not in the currently active EditPane along with a +line: that requires scrolling. It should be low risk.

The caret will still disappear. I suspect that view.requestFocus() is putting the focus on a slight superset of the textarea. Ctrl+A does still select the textarea even if there is no cursor. In some cases one tab key press brought the cursor back, suggesting that the tab was following a focus cycle or even focus cycling from the textarea to the textarea. You can also try commenting out the EditServer view.requestFocus() and see if that works for you on your platform.