Bo Peng wrote:
I tried using updateParam() after introducing getTeXFile, but that
didn't work. The problem is that there's no way to tell when you get
back from EmbeddedFiles what the ORIGINAL path was. Things like: biblio,
../biblio, /home/me/biblio, etc, all look the same to EmbeddedFiles at
that point, because it just has an absolute path. So I more or less went
back to the old code, fixed up a bit.
There are problems with your approach as well. When EmbeddedFile is
copied to another buffer, with a different bufferPath, bib1.bst
automatically becomes, for example, buffer1/bib1.bst. I can not see
how this is possible with your approach.
I take it that you're talking about copyTo(), right? I'm not sure I see
the problem in InsetInclude. There, the EmbeddedFile ends up getting
used as little more than an intermediary towards setting the embed
parameter. InsetGraphics and InsetExternal are a different matter,
because they don't use the InsetCommandParams infrastructure. And there,
a FileName was always part of the parameters, from what I can tell, so
there's not really so much of a change. And those are the only places
this method gets called, so far, anyway.
There must be a better way to handle this relative path mess....
Well, we need some general solution, because there are similar problems
elsewhere. If you have a file that contains a path to an included file,
for example, it can be changed simply by opening and saving the file. In
particular, it will always be converted from an absolute to a relative
path, and relative paths can be changed when you save. (With graphics,
it seems you can't even store an absolute path, which seems wrong, too,
but this is an older issue.) The problem, in general, seems to me to be
that the updateEmbeddedFile method is modifying the path to the included
file. I can see why it might need to modify the embed parameter, but why
should it be modifying anything else? Is there some reason we need the
first line:
void InsetInclude::updateEmbeddedFile(EmbeddedFile const & file)
{
setParam("filename",
from_utf8(file.outputFilename(buffer().filePath())));
setParam("embed", file.embedded() ? from_utf8(file.inzipName()) :
docstring());
}
That's the offender. I don't think removing it affects the copyTo()
issue. That's handled in setBuffer().
In the case of InsetBibtex, I think maybe an approach more like the one
in InsetInclude might work, where there aren't any "local" EmbeddedFile
objects but only the ones in the Buffer-level EmbeddedFileList.
InsetBibtex could have a vector of EmbeddedFile* instead, where these
are returned by registerFile(). So far as I can now see, the
EmbeddedFile objects aren't actually doing anything in InsetBibtex but
are, again, acting more as intermediaries. Removing them from
InsetBibtex would mean a few changes elsewhere, too, but not many, and
it would restore the "purity" of the inset.
Richard
