A fix for the issue has been committed in r59596.
I believe it is an issue in Windows itself. Though it is bound to rather complex conditions, which is why it may not be seen in other apps.
Except a very similar (but maybe different) issue exists in wordpad, where instead of ghost carets, the last line of text (before scrolling start) is repeated over and over, if the bottom of wordpad is off-screen.
To trigger the issue conditions as mentioned below must be present.
Since most editors, will simple invalidate the entire line (gutter, text and all), in those apps the issue never manifests.
SynEdit attempts to be to clever. Yet that it works, if the caret is "on screen", indicates that it is meant to work.
To reproduce, the editor must have a visible gutter; and must not have "current line" highlight.
* The conditions to cause this:
- Caret must be in part of editor that is outside the screen.
- Caret must be destroyed (maybe only hidden?), or ScrollWindowEx must affect caret
- Caret must be in a part of the editor for which NO call to "invalidate" was made,
but which will be repainted. (repaint uses the minimum rect enclosing the combination of *all* invalidates)
E.g. the gutter, but not the line area received an invalidate, and another line above/below was invalidated
(can happen through ScrollWindowEx). -> In this case the paint message receives a rect, that contains the caret,
even though the part containing the caret was never explicitly invalidated.
If this happens, while the caret is on screen (even if hidden behind another window/taskbar) then all works ok.
But if the caret was off screen, a permanent image of the caret will remain (once scrolled/moved into the screen area).
It seem that in this case windows does not update the information, that the caret became "invisible" when paint did paint
over it. So if the already overpainted caret, is later (by Windows) attempted to be hidden by a final "xor", then it actually
is made permanently visible.