>>>>> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Juergen Spitzmueller wrote: >> http://bugzilla.lyx.org/show_bug.cgi?id=961 >> >> The attached patch reimplements those lfuns. It also fixes >> InsetBibtex::delDatabase, which is broken in 1.3. >> >> The only drawback is that the lfuns are not working when the cursor >> sits behind the inset. The same applies to 1.3. The reason is that >> getInsetByCode stops at the end of the document. Juergen> Attached is a third (and IMHO final) version that fixes all Juergen> drawbacks and additionally also fixes a problem in Juergen> InsetBibtex::addDatabase, which did not add a database when Juergen> its name was a substring of another database (e.g. "mybib" Juergen> vs. "mybib2"). I do not like what you do to getInsetByCode. IMO, this method is only supposed to return the inset at cursor position if it exists (nextInset does not iterate anything). I really think that what you need is the functionality of bv_funcs::gotoInset that finds an inset by code. Of course, it is a bit different since it sets bv->cursor(), but it would be possible to factor the code to extract the isnet finding code. We would then have two functions: - getInsetByCode returns the inset at cursor if it has the right code, and 0 otherwise. - findInset (or whatever) would modify the cursor passed to it (or return a new cursor) to point to the inset. gotoInset could be changed to be based on it. My point is that the behaviour of getInsetByCode is intended and should be left alone. JMarc
