On Sat, Jan 21, 2006 at 02:13:47PM +0200, Martin Vermeer wrote: > On Fri, Jan 20, 2006 at 10:06:15PM +0200, Martin Vermeer wrote: > > On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote: > > > >>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > ... > > > It's snappy for me... BTW there is something rotten also in cursor > > positioning _inside_ math arrays, both regarding correctness and speed. > > About the rottenness, one thing is that in bruteFind2, the co-ordinates > xo, yo produced by the cursorPos call are relative, while the arguments > coming from the header x, y are absolute... the attached fixes it and > now movement between cells in an array, each of which contain multiple > stuff, is reasonable.
Ah, very good you found this one. > Even x_target is being honoured now inside math. > This is just plain right and should go in. > > BTW, in > > inset->cursorPos(it.top(), c.boundary() && ((i+1) == it.depth()), xo, yo); > > what precisely is the (i+1) == it.depth() condition for? Definitely not my code. I'd have written inset->cursorPos(it.top(), c.boundary() && i + 1 == it.depth(), xo, yo); or similar. Given that 'boundary()' appears nearby, I'd guess Juergen V. would possibly know. > [...] (Andre' should have had his coffee before trying to code ;-) I am clean since mid-November. I had a single cup of coffee since then (at an opportunity when declining the offer would have been very impolite) and no black tea. > BTW2, we still have the cursor movement bug that the cursor doesn't > move straight into an equation, but moves first to the left side of it, > and only then in (to the correct x position too) on the next cursor > up/down. This appears to be connected with checkInsetHit and editXY, > which ought to be called recursively but don't seem to be. Someone > should look into that. You seem to be good at looking into things. And I'd think outdoor activities would have quiet down at this time of the year... Andre'
