Bo Peng wrote:
I wasn't trying to argue. I was trying to collaborate. But you are so
protective of your code that you won't even let me fix the bugs YOU created.
protective?? right. Note that your patch came before you understood
how embedding works.
That was several patches ago. God forbid I might have had trouble
understanding your code.
The example wasn't idle. Using a map in InsetBibtex is totally natural:
Come on, if you use a map, you open a file with embedded files and
save it. The embedded files may be saved in a different order and
result in a totally different .lyx file. It is lucky that you are not
supposed to svn an embedded .lyx file.
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.
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?
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.
rh
