Andre Poenitz wrote: > On Tue, Jun 24, 2003 at 07:09:47PM +0200, Alfredo Braunstein wrote: >> Andre Poenitz wrote: >> >> > But in addition to the purely cosmetic issues of 'noupdate 2', there >> > are now lots of (unfixable) hard crashs. The reason is mainly the >> > current cursor implementation. The stored row iterators get invalidated >> > pretty fast -> boom. >> >> Probably I wouldn't be so hard to eliminate the cached cursor row for the >> time being (a matter of replacing all calls cursor.row by cursor.row() I >> suppose). We can for the time being make cursor.row to recompute the row >> at every call, and maybe later opt for a different solution. What do you >> think? > > To recompute the row we'd need at least some kind of access to the row > list, i.e. either some pointer/reference to the row list, or the text, > or make cursorRow() a member of the text. I would have tried the last one > first, but if you see a possibility to recompute the row without explicit > access to row list or text I'd prefer that.
Dunno, do you think it is feasible to replace all uses of cursor.row by calls to cursor.row(LyXText &) or something? Alternatively, something like getRow(cursor, LyXText &) > Long term goal is of course to completely separate the cursor from the > text be using 'deep iterators' (i.e. something pretty much like > ParIterator right now, but with an additional field to indicate the > position in the paragraph...) Aren't these different issues? As I see it, this last one is how to identify the paragraph/position in which the cursor is (buffer related). The problem of invalidation of cursors on rebreaking is /if/how to/ keep the information in which row it is. Of course, the two will become more related if in the future each paragraph store its own RowList. Is this what you are referring to? Alfredo
