Andre Poenitz wrote: > On Wed, Aug 22, 2007 at 04:55:13PM +0200, Alfredo Braunstein wrote: >> Abdelrazak Younes wrote: >> >> > Alfredo Braunstein wrote: >> >> Abdelrazak Younes wrote: >> >> >> >>> Well, at runtime, in-inset bookmark sort of work now because we >> >>> already use the paragraph id. What is missing is the saving/loading >> >>> of in-inset bookmark when a document is opened/closed. >> >> >> >> I see (missed the point) :-) >> > >> > Still, you are welcome to proceed to your idea ;-) >> >> I don't have a good idea unfortunately. As I see it there are many >> approaches, but all of them are bad in one way or another. >> >> 1) the current approach with par ids has two problems >> a) when the paragraph get erased we lose track of everything >> b) edition of chars in the paragraph before the position >> move the bookmarks >> >> 2) one idea would be to use a special mark inset. This would solve b) but >> not a). Aditionally, this implies that we have an undesired object that >> obstacles edition. We could try to track its existence with a signal in >> its dtor, but seems difficult to readjust correctly (in particular hard >> to avoid a large number of operations when a large block gets >> inserted/deleted etc) >> >> 3) finally, registering with the buffer. Then all edit operations have to >> be done in a centralized way. This is difficult to enforce, we should >> make Paragraph/ParagraphList/Inset accessor methods private and work our >> way with friend functions/classes that track the bookmarks. Seems lot of >> work. >> >> Other ideas? > > 3. A lot of work, but it will pay off..
I've rethink about it, and I think that there's a plausible solution near 2) that requires much less work. The idea is the following: we have special marks inside the insetlist inside paragraphs, administrated by insetlist. They don't occupy editing space, but are adjusted as insets on edition. They are also centrally registerd (smart pointers or such). On deletion, (be it because the position is deleted, or because the paragraph is), they signal their deletion to the central register. Once after each user edition (in some central dispatch), all newly deleted marks are repositioned in the cursor position of the cursor [of the Bufferview] that made the edition (this is ok, because we already track this cursor position in edit routines, and all 'deleted' positions collapse in the final cursor position). What about this? A/
