Bo Peng wrote:
Please see my other message. What Andre envisages is rolling
InsetCommandParams into the insets. That could be done, of course, but there
are at least some reasons not to do it. The reasons not to do it are the
same as the reasons to have InsetGraphicsParams be separate from
InsetGraphics, so this has nothing to do with ICP as such.
Another option, perhaps the one you have in mind, is to ditch ICP
altogether here and do for InsetBibtex what is presently done for
InsetGraphics and InsetExternal, namely, to give them there own parameter
class built from scratch. But I can see no good reason to do that. And at
present, there is massive code duplication in those two classes. I don't see
why we should add to the chaos.
I have had limited experience with InsetCommand, all of them were
pretty negative. In the case of InsetBibtex, making a comma separated
string as the core structure, and parsing it each time looks really
awkward to me.
I agree. The alternative I suggested would avoid this. All of this is a
remnant of a much older system, according to which an inset's data was
stored simply in the form of a LaTeX command string. I'd rather we
stored lists like this:
bibfile biblio1
bibfile biblio2
This seems especially important with the embed parameter. It's unusual,
but /home/heck,rg/biblio.bib is a perfectly valid filename. It would
break our system right now.
If this was acceptable before the embedding age, it is
not acceptable when two sets of data structure are used to represent
basically the same information and we have to keep them synced.
I would not hesitate at all, to build EmbeddedFIleList when the inset is
loaded, manipulate it, and convert it to the latex string when the
inset is saved. This has been done for InsetGraphicsParams where
EmbeddedFile is used, and I think this is, IMHO, the right thing to
do.
I haven't looked enough at IGP to know whether there are potential
problems there like the ones we have been discussing here. If so, then
so; if not, not. What I do know, as I've said, is that there is massive
duplication of code.
rh
