This is one of the strangest bugs I've ever seen. After extensive research, I can see nothing obviously wrong with Leo's code, but clearly something was wrong somewhere.
Rev 5259 fixes this bug, apparently, by having v.restoreCursorAndScroll always call setSelectionRange with "full" parameters, that is, by explicitly specifying the "insert" argument. This fixes the reported symptoms, but it is still unclear what was going on.
Extensive testing showed that at no time was data ever lost, even though body text was incorrectly rendered. It's possible that somehow setting the insert point while leaving the selection range as it was somehow confused the *Qt* colorizing code, but it is fairly clear that at no time did *Leo's* colorizing code ever become confused.
g.restore_selection_range has been removed. It was only ever used in v.restoreCursorAndScroll.
This is one of the strangest bugs I've ever seen. After extensive research, I can see nothing obviously wrong with Leo's code, but clearly something was wrong somewhere.
Rev 5259 fixes this bug, apparently, by having v.restoreCursor AndScroll always call setSelectionRange with "full" parameters, that is, by explicitly specifying the "insert" argument. This fixes the reported symptoms, but it is still unclear what was going on.
Extensive testing showed that at no time was data ever lost, even though body text was incorrectly rendered. It's possible that somehow setting the insert point while leaving the selection range as it was somehow confused the *Qt* colorizing code, but it is fairly clear that at no time did *Leo's* colorizing code ever become confused.
g.restore_ selection_ range has been removed. It was only ever used in v.restoreCursor AndScroll.