PreviousNextTracker indexSee it online !

(81/211) 3604 - Copying a file causes repaint to fail.

I racked my brain out trying to find out what was causing this issue. Periodically, while switching from the editor to ftp and then to browser, upon switching back to the editor, the only item displayed would be the title bar. Dragging the window off screen and back did not force a refresh. It only caused the wavy line effect you get when dragging windows around and windows gets bogged down trying to keep up with a screen refresh.

Finally, I figured out what was going on and it is definitely a bug within the core of the editor. In the editor I have the registers as a dockable window and always visible as I am regularly copying and pasting a variety of code from multiple sources, using several registers at once. The problem only comes up when I switch to explorer and copy a file to paste into my ftp application. After copying the file, jEdit fails to update any of its buffers or windows until I select some text and copy it into the clipboard. (BTW--after the problem is fixed by selecting text, I still have to switch applications, or minimize-restore to trigger a repaint, but from then on it will work until I have to copy a file again.) I think this is due to the clipboard register always being present and displayed.

The error does not happen if the registers window is not visible, but if you click the button to display it while windows has a file in the clipboard, it has the same problem.

Submitted *anonymous - 2011-11-08 19:45:29 Assigned kpouer
Priority 5 Labels editor core
Status open Group severe bug
Resolution None

Comments

2011-11-08 20:00:32
*anonymous

Correction,

If the register window is not visible, it does not appear to cause the problem at first, but it still occurs intermittently. The only sure fire way to resolve the problem is to always copy some text from the browser before returning to jEdit.
2011-11-08 20:13:01
*anonymous

I've experimented some more, and if it is undocked, it does not cause the painting issue. There is still a Null Pointer error and a host of other errors caused by this condition. If undocked, the window will change to say "No registers defined." and will clear the second box. However, if docked, it tries to display the $ (clipboard) register in the top pane, and in the bottom pane, the content is not updated.

This can be seen by copying some text, then switching to another application and copying some other text. The top pane changes, but the lower pane does not. I guess this could be considered a seperate bug, but I think they may be related.
2011-11-08 20:19:21
*anonymous

Wouldn't you know, as soon as I added the last comment, I find another fact.

The problem only occurs if the $ (clipboard) register is being displayed. In other words, even if the registers window is docked, if the $ register is not being displayed, then the error does not occur.
2011-11-08 21:23:41
*anonymous

It's not perfect, but until a fix can be given, I've made a macro that can help. It clears the register, then creates a copy of the current view in place, and removes the copy of the view, effectively forcing a repaint. Just save the following two commands to a file with a .bsh extension in the macros directory:

Registers.getRegister('$').setValue("");
jEdit.closeView(jEdit.newView(view));

Then I recommend assigning it to a keyboard shortcut you can easily remember. I used Control-Shift-F12, but you could use anything not already used. I tested this on mine, but I can't guarantee that there won't be any side effects from this with other configurations. One thing to note, this does clear the $ (clipboard) register, but seeing as that is what you want, not really a problem.

Also, on my system, the previous content was still available in the lower pane of the registers window and could be selected, copied, and pasted. Caution for multiple register users: It is only available until you change registers, so if you may need it, copy it from the lower pane before accessing another register.