On Mon, 2005-11-07 at 08:02 +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > 207 BOOST_ASSERT(status() != Collapsed); > > > > Question: why does this _normally_ not trigger an assert, even if the > > inset is closed? And why does it when coming directly from a mathinset? > > Because the inset should always be opened as soon as a cursor is inside. This > is assured by > > 132 autoOpen_ = mi.base.bv->cursor().isInside(this); > > So it seems that in the crash scenario the cursor is entering the inset in > some illegal way. Could it be that the depth is not reset properly when the > cursor leaves the math inset, so that it thinks it is in the collapsable when > it has been moved to that par (just a wild, wild guess)?
Actually I don't think so. The crash happens also if you have a collapsed inset inside an uncollapsed inset on the lower row, and the cursor doesn't even enter the outer inset when going down. What happens is that somehow, after the "updown: popleft failed (strange case)" message, bruteFind is called, which scans the whole visible screen. One step at a time using forwardPos. And then returning the "best" cursor position. The problem now is the call to bv_funcs::getPos (line 135 of cursor.C), which is called for _every_ position traversed by forwardPos. Clearly it shouldn't visit positions inside a collapsed inset, but apparently it does. (And then coordOffset gets called, and then sl.inset().cursorPos for a collapsed inset, and boom.) I am looking at the test bv_funcs::status(&cursor.bv(), it) == bv_funcs::CUR_INSIDE (cursor.C:133). This status function (at bufferview_funcs.C:220) test whether at location it (the dociterator) there is a paragraph registered in the paragraph cache. If there is, the value CUR_INSIDE is returned. Question: shouldn't the paragraph(s) inside a collapsed inset be absent from the paragraph cache? - Martin
signature.asc
Description: This is a digitally signed message part
