On Fri, Mar 19, 2010 at 1:25 AM, Dov Feldstern <d...@lyx.org> wrote: > On Fri, Mar 19, 2010 at 1:22 AM, rgheck <rgh...@bobjweil.com> wrote: >> On 03/18/2010 07:01 PM, Dov Feldstern wrote: >>> >>> So, in order to figure this out, I added the debug prints mentioned >>> above, and then I noticed that only when we're at the end of a word, >>> but not anywhere else, then a line is printed every time the cursor >>> blinks --- whether or not the cursor is on the screen. >>> >>> >> >> I've seen this, too. Surely it would make sense to disable the cursor >> blinking when the little guy is off screen, right? Perhaps that is the real >> bug. But still, I think my patch makes sense. I see TONS of metrics being >> calculated when I move the mouse, which is very weird---the point being that >> we can't be quite sure when isRTLBoundary might be called. So we should make >> sure we have metrics, like we make sure we have a non-null pointer. >> >> I think the issue here, in a way, is that >> par_metrics_[pit] >> has a nasty side effect. Maps can be dangerous. >> >>> In other words: something is causing isRTLBoundary to be called every time >>> the >>> cursor blinks when it is at the end of the word, even if it is off the >>> screen, and the first time that that happens, there are no metrics! >>> >>> >> >> As Vincent notes, the "end of the word" thing is due to something in >> getFont(). >> >> So I'd suggest we do two things: (i) commit the check for metrics, which >> makes sense anyway; and (ii) disable the cursor blinking when the cursor is >> off-screen, which also makes sense anyway. >> > > Sounds good to me... I just want to double check that your change > doesn't adversely affect the test-case for which that code was > originally added --- I'll get back to you on that in a few minutes... > >> rh >> >> >
hmpph, it's broken both with and without your changes, and even without getting RTL involved: abc\n <- soft line break def if you are after the 'd', it takes 4 presses of Left to get to before the 'c', but only 3 presses of Right to then get back to the same position, because of the boundary... But anyhow, yeah, the patch seems fine. However, it may be worth revisiting http://www.lyx.org/trac/ticket/5061 (though the behavior I describe as problematic is not exactly that described in the bug, I think...).
