> But I disagree that embedded objects are parameters. In particular, I think > using an EmbeddedFile object to represent a pair of strings is overkill that > ultimately makes the code less comprehensible and less maintainable, because > (a) changes to the EmbeddedFile stuff could in principle affect the inner > workings of the insets and (b) you can't work on the inset without figuring > out the (extremely complex) EmbeddedFile code. (Somewhere in there is the > reason kpsewhich support got broken, and there are still bugs elsewhere that > we have for similar reasons.) As far as I'm concerned, it's no argument that > the EmbeddedFile objects are already lying around. They should do the work > they need to do and leave the rest of the inset alone. And I'd feel exactly > the same way about this if we were talking about InsetBibtexParams. This > issue has nothing to do with ICP.
Unless the current embedding design is revoked (let us discuss this in another thread), EmbeddedFileList (for a list of embedded bib file), or EmbeddedFile (for a embedded graphics or included file) have to be involved in these insets, becuase they dictate how these insets should behave at runtime. As I have showed you, there is no way to separate them from the core params, and I would like to go further to replace the core params with EmbeddedFileList in InsetBibtex, as what I have done for InsetGraphics. This may be complicated, but there is no way around. Bo
