Georg Baum wrote:
Abdelrazak Younes wrote:
OK then, IIUC, the attached patch is correct for all use-cases:
1) if a bib file is found in the same directory of the lyx file, this is
the one.
2) if not look in the cache.
3) if not in the cache, look for it with kpsewhich.
Now you duplicated partly what findtexfile does. Not good IMHO.
Agreed but, well, I wanted to remove this code from findtexfile but then
it is used in Latex.C and I am not sure it is useful there.
In practice, this means that we cache only files that are in the texmf
tree and there is no room for confusion.
Not good. We should cache all files. This makes the code simpler.
As you prefer... It can be done with a map. No strong opinion on that...
As an added bonus, the patch also avoid the use of 'Path'.
At the cost of duplicated code. I prefer using Path and one utility function
over not using Path but duplicating the code.
Personally I don't like utility function that do two independant things
like this finxdtexfile(). An utility function should do one thing and do
it well IMHO.
By the way, is it normal that we don't allow bib files outside the texmf
tree or along the lyx file?
As Jürgen already said: We allow them. If the dialog would not allow to add
them then that would be a different bug, but in fact that works here. The
dialog is only clever: It strips the path if the file is in the same
directory as the document.
Well, I think this is misleading somewhat. Because if you use a local
bib file that has the same name as one in the Textmf tree, then you
don't know which one you are using. I think we should prefix './' to the
local one.
It does not do so if it is somehere completely
else, and you give the absolute path. We do this for all included files
BTW, and it makes sense: Usually if I include files in the same directory
or a subdirectory I want relative paths, because I can then transfer the
whole document easily.
Agreed but for me relative path means './toto' and not 'toto'.
Abdel.
