> You STILL don't understand the point. This isn't about > Buffer::embeddedFile(), which is what is used to save the zip file. It's > about the bibfilesCache_, which is a totally separate thing.
I though that you are changing EmbeddedFileList from vector<EmbeddedFile> to map<docstring, EmbeddedFile>. This will of course change buffer level embedded file list. > Look, I want to make bibfilesCache_ a map. I have very good reasons to > want to do this. I therefore want InsetBibtex::getBibFilesCache() to > return such a map. (I suppose it could return something else, and then I > could do some conversion, but why?) Back in InsetBibtex, I can produce > the map from an EmbeddedFileList, but the much easier thing to do is to > have InsetBibtex::bibfiles_ itself be such a map, and I'll just return a > const reference to it---just like we do now. If your implementation of > the embedding feature prohibits me from doing this, then that, it seems > to me, is a big problem. Do you think it does? If not, is it OK with you > if I make this change? What is the key to this map? If it is biblio, not /path/to/biblio.bib, then you can make bibfiles_ a map, and the meta_ patch is no longer needed. A complication here is that registerEmbeddedFile has to ask params for the order of the files.... this is in the end not so good. > And second: If the order of the embedded files in the LyX file matters, > then you'd better check the code, because it simply does not guarantee > that the order will not change after minor edits. It is also false that > it might change after an open/save sequence, unless you've moved > systems. But in that case, it may change anyway. The current code will not change the order of embedded files, unless you use a map to return bib files without order from InsetBibtex. Bo
