Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
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,
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> 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
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Could you test the attached patch nevertheless? Or Georg maybe?
It fails whenever different documents use different bib files of the same name
(without absolute path).
Consider the following case:
- I have a file one.lyx in directory
Abdelrazak Younes wrote:
By the way, is it normal that we don't allow bib files outside the texmf
tree or along the lyx file?
We allow them, but they are identified with (absolute or relative) path,
whereas those in the texmf tree or the same directory are only stored as file
names.
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
By the way, is it normal that we don't allow bib files outside the texmf
tree or along the lyx file?
We allow them, but they are identified with (absolute or relative) path,
whereas those in the texmf tree or the same directory are only
Abdelrazak Younes wrote:
Then there is bug somewhere because selecting any bib file in the BibTex
dialog will always truncate the path and the extension. So I am afraid
that there is no way to select a file that is not in the textmf tree or
in the same directory.
Works for me (via
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
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Then there is bug somewhere because selecting any bib file in the BibTex
dialog will always truncate the path and the extension. So I am afraid
that there is no way to select a file that is not in the textmf tree or
in the same directory.
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak * stripped file name for file in the current directory.
- this should be changed to relative path (with './')
Why?
JMarc
Georg Baum wrote:
Abdelrazak Younes wrote:
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.
I thought a bit more about this and I think I disagree. It is OK to
Abdelrazak Younes wrote:
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.
It is used there on purpose IIRC. findtexfile was designed for exactly this
use case: Find a file, using the same search algorithm as
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak * stripped file name for file in the current directory.
- this should be changed to relative path (with './')
Why?
To be able to distinguish between this and a bibfile that have the same
name
Georg Baum wrote:
Abdelrazak Younes wrote:
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.
It is used there on purpose IIRC. findtexfile was designed for exactly this
use case: Find a file, using the same
On Tue, Jan 09, 2007 at 04:30:47PM +0100, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak * stripped file name for file in the current directory.
- this should be changed to relative path (with './')
Why?
Am Dienstag, 9. Januar 2007 16:46 schrieb Abdelrazak Younes:
Georg Baum wrote:
This was simply designed to work exactly as it works in LaTeX. If we
want to
change that, then we should not store the filenames in a comma
separated
list, but use something similar to the new
Am Dienstag, 9. Januar 2007 16:29 schrieb Abdelrazak Younes:
Georg Baum wrote:
Abdelrazak Younes wrote:
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.
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Could you test the attached patch nevertheless? Or Georg maybe?
It fails whenever different documents use different bib files of the same name
(without absolute path).
Consider the following case:
- I have a file one.lyx in directory
Abdelrazak Younes wrote:
> By the way, is it normal that we don't allow bib files outside the texmf
> tree or along the lyx file?
We allow them, but they are identified with (absolute or relative) path,
whereas those in the texmf tree or the same directory are only stored as file
names.
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
By the way, is it normal that we don't allow bib files outside the texmf
tree or along the lyx file?
We allow them, but they are identified with (absolute or relative) path,
whereas those in the texmf tree or the same directory are only
Abdelrazak Younes wrote:
> Then there is bug somewhere because selecting any bib file in the BibTex
> dialog will always truncate the path and the extension. So I am afraid
> that there is no way to select a file that is not in the textmf tree or
> in the same directory.
Works for me (via
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
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Then there is bug somewhere because selecting any bib file in the BibTex
dialog will always truncate the path and the extension. So I am afraid
that there is no way to select a file that is not in the textmf tree or
in the same directory.
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> * stripped file name for file in the current directory.
-> this should be changed to relative path (with './')
Why?
JMarc
Georg Baum wrote:
Abdelrazak Younes wrote:
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.
I thought a bit more about this and I think I disagree. It is OK to
Abdelrazak Younes wrote:
> 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.
It is used there on purpose IIRC. findtexfile was designed for exactly this
use case: Find a file, using the same search algorithm as
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> * stripped file name for file in the current directory.
-> this should be changed to relative path (with './')
Why?
To be able to distinguish between this and a bibfile that have the same
Georg Baum wrote:
Abdelrazak Younes wrote:
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.
It is used there on purpose IIRC. findtexfile was designed for exactly this
use case: Find a file, using the same
On Tue, Jan 09, 2007 at 04:30:47PM +0100, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> > Abdelrazak> * stripped file name for file in the current directory.
> > -> this should be changed to relative path (with
Am Dienstag, 9. Januar 2007 16:46 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > This was simply designed to work exactly as it works in LaTeX. If we
want to
> > change that, then we should not store the filenames in a comma
separated
> > list, but use something similar to the new
Am Dienstag, 9. Januar 2007 16:29 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > Abdelrazak Younes wrote:
>
> >> 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
Hello,
This update showed in Edwin's recent profile results. I reckon that one
does not need to have immediate use of the cache; especially if he/she
just want to visualize the document.
Juergen, I know you are a heavy bibtex user, is this acceptable to you?
Abdel.
Index: buffer.C
Jürgen Spitzmüller wrote:
The bibfiles cache is needed when you load a document with natbib citations
(to correctly display the natbib style in the citation insets). I suspect
your patch will break this, and then it'll be not acceptable IMHO.
No, it seems to work nevertheless. Put in in, we
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
The bibfiles cache is needed when you load a document with natbib citations
(to correctly display the natbib style in the citation insets). I suspect
your patch will break this, and then it'll be not acceptable IMHO.
No, it seems to work
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
The bibfiles cache is needed when you load a document with natbib citations
(to correctly display the natbib style in the citation insets). I suspect
your patch will break this, and then it'll be not acceptable IMHO.
No, it seems to work
Abdelrazak Younes wrote:
I am not sure I sent out the complete patch earlier and I might have
gone too fast with the last commit. Could you please svn update and test
a file with natbib citations? In principle this should be OK as the
cache is private and is always accessed through
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I am not sure I sent out the complete patch earlier and I might have
gone too fast with the last commit. Could you please svn update and test
a file with natbib citations? In principle this should be OK as the
cache is private and is always
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I am not sure I sent out the complete patch earlier and I might have
gone too fast with the last commit. Could you please svn update and test
a file with natbib citations? In principle this should be OK as the
cache is
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I am not sure I sent out the complete patch earlier and I might have
gone too fast with the last commit. Could you please svn update and test
a file with natbib citations? In principle this should be OK as the
cache is
Abdelrazak Younes wrote:
And this one:
// Cache the labels
typedef std::mapBuffer const *, biblio::InfoMap CachedMap;
static CachedMap cached_keys;
Well, this could be the culprit indeed.
Did I say already that static variables are evil?
I'm sure you did.
Please
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
The only case where it doesn't work is if you close and reopen a file
without closing LyX, but this is unrelated to your patch (maybe you
have an idea nevertheless?)
Does natbib support code uses some static
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
And this one:
// Cache the labels
typedef std::mapBuffer const *, biblio::InfoMap CachedMap;
static CachedMap cached_keys;
Well, this could be the culprit indeed.
Did I say already that static variables are evil?
Abdelrazak Younes wrote:
Did this ever work?
It works pretty well (except for the minor glitch I just mentioned). And it
was a massive speedup improvement.
Jürgen
Georg Baum wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
The only case where it doesn't work is if you close and reopen a file
without closing LyX, but this is unrelated to your patch (maybe you
have an idea nevertheless?)
Does natbib support code uses
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Did this ever work?
It works pretty well (except for the minor glitch I just mentioned).
That was my question.
And it
was a massive speedup improvement.
But this is still working right?
Abdel.
Abdelrazak Younes wrote:
But this is still working right?
Yes. I'll investigate if I can fix the glitch (which has been there from the
beginning I think).
Jürgen
Abdelrazak Younes wrote:
I don't see this kpsewhich being called anywhere here. Could you please
enlighten us?
it gets called via findtexfiles, which is called in insetbibtex, which is
queried by the bibfilescache.
Jürgen
Abdelrazak Younes wrote:
Georg Baum wrote:
Not all static variables are evil,
sometimes they are exactly the right tool for the right job.
Sure, when you know what you are doing...
Exactly. In this case, at a first glance, I think your suggestion to
transfer it to the buffer would also
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I don't see this kpsewhich being called anywhere here. Could you please
enlighten us?
it gets called via findtexfiles, which is called in insetbibtex, which is
queried by the bibfilescache.
So this has nothing to do with those two static
Abdelrazak Younes wrote:
So this has nothing to do with those two static variables inside
insetcite.C right?
Well, indirectly. The timestamps are stored there.
If I am right, then you just need to transfer the cached_keys variable
to Buffer.
And if I am still right then the problem with
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Not all static variables are evil,
sometimes they are exactly the right tool for the right job.
Sure, when you know what you are doing...
Exactly. In this case, at a first glance, I think your suggestion to
transfer it to the
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
yes, I think so. The problem was that we checked if the cache was empty, not
if the cache did not contain data for the current buffer. The attached patch
fixes this. I'd propose to shove this in despite what we are doing later. I'd
also like
Abdelrazak Younes wrote:
I see. There's something wrong with nsetBibtex::getFiles(Buffer const
buffer), buffer is not used at all.
Sure it is:
Path p(buffer.filePath());
The local vectorFileName vec in
this method is the one that needs to be cached.
I don't think so. It is returned in
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I see. There's something wrong with nsetBibtex::getFiles(Buffer const
buffer), buffer is not used at all.
Sure it is:
Path p(buffer.filePath());
p is not used.
The local vectorFileName vec in
this method is the one that needs to be
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I see. There's something wrong with nsetBibtex::getFiles(Buffer const
buffer), buffer is not used at all.
Sure it is:
Path p(buffer.filePath());
p is not used.
It is, by simply instantiating the variable.
Abdelrazak Younes wrote:
The local vectorFileName vec in
this method is the one that needs to be cached.
I don't think so. It is returned in the function.
I know, but look more closely to the code. My point is that this code is
independent from the given Buffer. AFAIU, BibTex database
Abdelrazak Younes wrote:
This update showed in Edwin's recent profile results. I reckon that one
does not need to have immediate use of the cache; especially if he/she
just want to visualize the document.
Juergen, I know you are a heavy bibtex user, is this acceptable to you?
The bibfiles
Georg Baum wrote:
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I see. There's something wrong with nsetBibtex::getFiles(Buffer const
buffer), buffer is not used at all.
Sure it is:
Path p(buffer.filePath());
p is not used.
It is, by simply instantiating
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I think that if you close and reopen the file, the kpsewhich calls will
be called several times again.
Yes. And everytime you modify (one of) the bibtex inset(s). AFAIU this has to
be done, since we need to call kpsewhich for each bibtex
Abdelrazak Younes wrote:
The scanning of the bibtex files should be independent of the loaded
Buffer. Imagine you have two Buffers using the same bibtex file, the
same scanning will need to be done twice for no reason. Or maybe I am
missing something?
You're right, that could be optimized.
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
The scanning of the bibtex files should be independent of the loaded
Buffer. Imagine you have two Buffers using the same bibtex file, the
same scanning will need to be done twice for no reason. Or maybe I am
missing something?
You're right,
Abdelrazak Younes wrote:
Georg said that in his case it could be as long as 20 seconds because of
this scanning. That's why I talked about that since the beginning.
It don't think it'll take that long (for one scan). I used to have a full
TeXLive installation and several hundreds of bibfiles,
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Georg said that in his case it could be as long as 20 seconds because of
this scanning. That's why I talked about that since the beginning.
It don't think it'll take that long (for one scan). I used to have a full
TeXLive installation and
Abdelrazak Younes [EMAIL PROTECTED] writes:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
The scanning of the bibtex files should be independent of the loaded
Buffer. Imagine you have two Buffers using the same bibtex file, the
same scanning will need to be done twice for no reason.
Angus Leeming wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
The scanning of the bibtex files should be independent of the loaded
Buffer. Imagine you have two Buffers using the same bibtex file, the
same scanning will need to be done
Am Montag, 8. Januar 2007 18:58 schrieb Abdelrazak Younes:
The scanning of the bibtex files should be independent of the loaded
Buffer. Imagine you have two Buffers using the same bibtex file, the
same scanning will need to be done twice for no reason. Or maybe I am
missing something?
I
Am Montag, 8. Januar 2007 19:29 schrieb Abdelrazak Younes:
Could you test the attached patch nevertheless? Or Georg maybe?
I don't have a large natbib test doc, sorry.
Georg
Abdelrazak Younes wrote:
Could you test the attached patch nevertheless? Or Georg maybe?
It fails whenever different documents use different bib files of the same name
(without absolute path).
Consider the following case:
- I have a file one.lyx in directory /myfiles/one/ that includes a
Hello,
This update showed in Edwin's recent profile results. I reckon that one
does not need to have immediate use of the cache; especially if he/she
just want to visualize the document.
Juergen, I know you are a heavy bibtex user, is this acceptable to you?
Abdel.
Index: buffer.C
Jürgen Spitzmüller wrote:
> The bibfiles cache is needed when you load a document with natbib citations
> (to correctly display the natbib style in the citation insets). I suspect
> your patch will break this, and then it'll be not acceptable IMHO.
No, it seems to work nevertheless. Put in in, we
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
The bibfiles cache is needed when you load a document with natbib citations
(to correctly display the natbib style in the citation insets). I suspect
your patch will break this, and then it'll be not acceptable IMHO.
No, it seems to work
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
The bibfiles cache is needed when you load a document with natbib citations
(to correctly display the natbib style in the citation insets). I suspect
your patch will break this, and then it'll be not acceptable IMHO.
No, it seems to work
Abdelrazak Younes wrote:
> I am not sure I sent out the complete patch earlier and I might have
> gone too fast with the last commit. Could you please svn update and test
> a file with natbib citations? In principle this should be OK as the
> cache is private and is always accessed through
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I am not sure I sent out the complete patch earlier and I might have
gone too fast with the last commit. Could you please svn update and test
a file with natbib citations? In principle this should be OK as the
cache is private and is always
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I am not sure I sent out the complete patch earlier and I might have
gone too fast with the last commit. Could you please svn update and test
a file with natbib citations? In principle this should be OK as the
cache is
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I am not sure I sent out the complete patch earlier and I might have
gone too fast with the last commit. Could you please svn update and test
a file with natbib citations? In principle this should be OK as the
cache is
Abdelrazak Younes wrote:
> And this one:
>
> // Cache the labels
> typedef std::map CachedMap;
> static CachedMap cached_keys;
Well, this could be the culprit indeed.
> Did I say already that static variables are evil?
I'm sure you did.
Please feel free to change it (or
Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Jürgen Spitzmüller wrote:
>>> The only case where it doesn't work is if you close and reopen a file
>>> without closing LyX, but this is unrelated to your patch (maybe you
>>> have an idea nevertheless?)
>>
>> Does natbib support code uses
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
And this one:
// Cache the labels
typedef std::map CachedMap;
static CachedMap cached_keys;
Well, this could be the culprit indeed.
Did I say already that static variables are evil?
I'm sure you did.
Please feel
Abdelrazak Younes wrote:
> Did this ever work?
It works pretty well (except for the minor glitch I just mentioned). And it
was a massive speedup improvement.
Jürgen
Georg Baum wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
The only case where it doesn't work is if you close and reopen a file
without closing LyX, but this is unrelated to your patch (maybe you
have an idea nevertheless?)
Does natbib support code uses
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Did this ever work?
It works pretty well (except for the minor glitch I just mentioned).
That was my question.
And it
was a massive speedup improvement.
But this is still working right?
Abdel.
Abdelrazak Younes wrote:
> But this is still working right?
Yes. I'll investigate if I can fix the glitch (which has been there from the
beginning I think).
Jürgen
Abdelrazak Younes wrote:
> I don't see this kpsewhich being called anywhere here. Could you please
> enlighten us?
it gets called via findtexfiles, which is called in insetbibtex, which is
queried by the bibfilescache.
Jürgen
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Not all static variables are evil,
>> sometimes they are exactly the right tool for the right job.
>
> Sure, when you know what you are doing...
Exactly. In this case, at a first glance, I think your suggestion to
transfer it to the buffer would
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I don't see this kpsewhich being called anywhere here. Could you please
enlighten us?
it gets called via findtexfiles, which is called in insetbibtex, which is
queried by the bibfilescache.
So this has nothing to do with those two static
Abdelrazak Younes wrote:
> So this has nothing to do with those two static variables inside
> insetcite.C right?
Well, indirectly. The timestamps are stored there.
> If I am right, then you just need to transfer the cached_keys variable
> to Buffer.
> And if I am still right then the problem
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Not all static variables are evil,
sometimes they are exactly the right tool for the right job.
Sure, when you know what you are doing...
Exactly. In this case, at a first glance, I think your suggestion to
transfer it to the
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
yes, I think so. The problem was that we checked if the cache was empty, not
if the cache did not contain data for the current buffer. The attached patch
fixes this. I'd propose to shove this in despite what we are doing later. I'd
also like
Abdelrazak Younes wrote:
> I see. There's something wrong with nsetBibtex::getFiles(Buffer const &
> buffer), buffer is not used at all.
Sure it is:
Path p(buffer.filePath());
> The local "vector vec" in
> this method is the one that needs to be cached.
I don't think so. It is returned in the
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I see. There's something wrong with nsetBibtex::getFiles(Buffer const &
buffer), buffer is not used at all.
Sure it is:
Path p(buffer.filePath());
p is not used.
The local "vector vec" in
this method is the one that needs to be cached.
Abdelrazak Younes wrote:
> Jürgen Spitzmüller wrote:
>> Abdelrazak Younes wrote:
>>> I see. There's something wrong with nsetBibtex::getFiles(Buffer const &
>>> buffer), buffer is not used at all.
>>
>> Sure it is:
>> Path p(buffer.filePath());
>
> p is not used.
It is, by simply instantiating
Abdelrazak Younes wrote:
> >> The local "vector vec" in
> >> this method is the one that needs to be cached.
> >
> > I don't think so. It is returned in the function.
>
> I know, but look more closely to the code. My point is that this code is
> independent from the given Buffer. AFAIU, BibTex
Abdelrazak Younes wrote:
> This update showed in Edwin's recent profile results. I reckon that one
> does not need to have immediate use of the cache; especially if he/she
> just want to visualize the document.
>
> Juergen, I know you are a heavy bibtex user, is this acceptable to you?
The
Georg Baum wrote:
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I see. There's something wrong with nsetBibtex::getFiles(Buffer const &
buffer), buffer is not used at all.
Sure it is:
Path p(buffer.filePath());
p is not used.
It is, by simply instantiating
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I think that if you close and reopen the file, the kpsewhich calls will
be called several times again.
Yes. And everytime you modify (one of) the bibtex inset(s). AFAIU this has to
be done, since we need to call kpsewhich for each bibtex
Abdelrazak Younes wrote:
> The scanning of the bibtex files should be independent of the loaded
> Buffer. Imagine you have two Buffers using the same bibtex file, the
> same scanning will need to be done twice for no reason. Or maybe I am
> missing something?
You're right, that could be
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
The scanning of the bibtex files should be independent of the loaded
Buffer. Imagine you have two Buffers using the same bibtex file, the
same scanning will need to be done twice for no reason. Or maybe I am
missing something?
You're right,
Abdelrazak Younes wrote:
> Georg said that in his case it could be as long as 20 seconds because of
> this scanning. That's why I talked about that since the beginning.
It don't think it'll take that long (for one scan). I used to have a full
TeXLive installation and several hundreds of
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Georg said that in his case it could be as long as 20 seconds because of
this scanning. That's why I talked about that since the beginning.
It don't think it'll take that long (for one scan). I used to have a full
TeXLive installation and
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Jürgen Spitzmüller wrote:
> > Abdelrazak Younes wrote:
> >> The scanning of the bibtex files should be independent of the loaded
> >> Buffer. Imagine you have two Buffers using the same bibtex file, the
> >> same scanning will need to be done twice
1 - 100 of 104 matches
Mail list logo
