Bo Peng wrote:
> 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.
>
Yes. This is what I've been trying to say, more or less. But note that,
when we output latex, we iterate not over bibfiles_ but over params, and
we (quickly) look up the embedded file info in the map. We do it this
way because we should keep the order. This requires that bibfiles_ and
the params be in sync, but they have to be kept in sync anyway. We
resolved that issue a long time ago.
OK. We have agree upon at least a few things,
1. EmbeddedFileList (or map) has to be in sync with params, has to be
valid, so it can not be separated from params. In this sense, who
should be the core information (so that another one does not have to
be updated) is a false problem.
2. EmbeddedFile needs this meta_, and your solution of map<meta_,
EmbeddedFile> is acceptable to me. However, meta_ is a solution to a
general problem, that may be needed anyway in, for example,
InsetGraphics. I am not against the idea that you fix InsetBibtex now,
and fix InsetGraphic later.
We won't know this until we look at fixing that. I'm inclined, actually,
to do something more general, namely, to try to bring InsetGraphic into
the InsetCommand hierarchy. I think this was intended all along as part
of a more general transition that was never finished.
There are then some minor problems left, such as 1. In functions such
as addDatabase, should we update params first and update
EmbeddedFileList/Map; or another way around?
or encapsulate it in overridden setParam methods, so you can't forget to
do it.
2. When we are in need
some information, from whom should we ask for it? I say they are minor
problems because if params and EmbeddedFiles are in sync, it does not
really matter, so let use just use the easier method.
Iterating over params is more sensible, I think, if only because, if
embedding is not enabled, you needn't consult anything else. Exactly
what the code will look like, I don't yet know, but we'll have things like:
string const database =
buffer().enabled() ? consult(paramIterator->first) :
paramIterator->first;
We'd anyway have (more or less)
string const database =
buffer().enabled() ? bibfilesIterator->availableFilename() :
bibfilesIterator->metaInfo();
So it doesn't end up mattering that much, and the former makes it
clearer exactly where the information from EmbeddedFiles is used and
where it is not.
Anyway, it sounds as if we're well enough agreed that I can move ahead
with this.
rh
