Jean-Marc Lasgouttes wrote: > Richard> Here's another idea. Basically, what I've done is added an > Richard> optional "setFont" argument to editXY, so we can call it with > Richard> setFont = false during mere mouse movements and still take > Richard> advantage of its recursion without messing up the font. > Richard> setFont then has to be carried through the whole editXY > Richard> hierarchy. This seems like of silly, but it's probably just a > Richard> consequence of what Abdel suggested earlier: that editXY and > Richard> checkInsetHit may need re-factoring. editXY is doing two very > Richard> different things. > > Richard> Anyway, it can be made pretty later. The behavior ought to be > Richard> the same as before the previous patch. But I'm not entirely > Richard> sure I understand what behavior is wanted here. The insets > Richard> look very different from how they looked in the 1.4.x series. > > I did not closely follow this bug hinting frenzy, but are you sure > that what is missing is not just a LyXText::setCurrentFont(LCursor & > cur) at the right place? I do not see why there would be a need to > change fonts on a cursor move. Acually, I suspect that a > setCurrentFont call smewhere deep inside has been removed and it shows > all over the place. > I suppose that's possible, but the problem seems to me to be the opposite. The way the code was, editXY was being called in BufferView::workAreaDispatch for the sole purpose of finding the deepest inset over which the mouse pointer is located. But editXY does a lot else---it resets the cursor and calls LyXText::setCurrentFont, in particular. So it's not so much the lack of such a call as the presence of one in this method that was causing the problem. So it seems to me that, as Bo has said, the best thing to do here would certainly be to separate these two aspects: have one method that locates the deepest inset and another that will reset the cursor and font when that is required. But that seems like a lot of work right now.
Still, one pretty simple solution, I think, would be to reset the font at the end of GuiWorkArea::mouseMoveEvent: i.e., call setCurrentFont there. I'm pretty sure that would solve the problem for now. Richard -- ================================================================== Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ ================================================================== Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
