> 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. 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. Of course I also respect your chaos judgment. Cheers, Bo
