Re: better BibTeX support
On Mit, 14 Apr 1999 Allan Rae wrote: On Thu, 19 May 2135, Jochen Kuepper wrote: - sort the entries alphabetically. By taking a quick look at the sources this might be probably something for 1.1, when it uses a vector string , so you can just stable_sort that :-) If you use barracuda it will sort your .bib file for you in whatever order you wish including alphabetically. So rather than force any particular sort order on the keys I'd suggest we let the user sort their .bib file to suit their tastes and that way they might be able to navigate better. Well, the problem is I have several distinct databases. Each of this is sorted like I want it, but in the CombBox inside LyX the entries are put behind each other - first all keys from database 1, then 2, ... . Yes, I agree using barracuda is more advanced, just thought it would be nice. I actually "copied" the LyX code to KLyX, but there I just sort all entries into the Combo. I don´t know what container to use, if there's something like STL vector (tell me what to use) I can use in LyX-1.0 I would send in a patch. Greetings, Jochen --- Jochen Küpper Heinrich-Heine-Universität Düsseldorf [EMAIL PROTECTED] Institut für Physikalische Chemie I Universitätsstr. 1, Geb 26.43 Raum 02.29 phone ++49-211-8113681 40225 Düsseldorf fax ++49-211-8115195 Germany http://www-public.rz.uni-duesseldorf.de/~jochen ---
Re: better BibTeX support
On Wed, 14 Apr 1999 14:09:33 +1000 (GMT+1000), Allan Rae wrote: Arnd Yes, please make the forms bigger! The German po-file is great, [...] Making the forms bigger would create problems for systems with low resolution... We can't please everybody. The real solution would be to have a layout manager for xforms popups (or rather a real toolkit). Right, but the citation form specifically is quite small, so it shouldn't be a problem to make it, say, the same size as the reference window. Either that or use shorter keys ;P Or do the labels on the form get truncated as well? Yes, especially if you have two labels in a single line, only the first one is shown. Without looking at the english version you never will know they exist: This really is LyXing for initiated. I'm sure it's what you all are aiming at. :) Cheers, Arnd
Re: better BibTeX support
On Thu, 15 Apr 1999, Allan Rae wrote: In this case I'd prefer to have a marker or a label in the combox separating the different databases. Sorting them would obviously disrupt the order. I suppose it's a matter of how we each use the combox. That is, do we remember the keys we need or do we look them up in a bib-browser and then find them in the combox. If the latter is the case then we'd be much better off with a bib-browser that could insert the citation using the LyXServer. Yes, the combox can't be used in place of a bibtex browser. Alejandro had a patch for barracuda to do this (it might even be in the contrib directory). It should be somewhere, I remember I posted it years ago. I'll look for it but it's not hard to add this support to barracuda, using the lyxserver examples as a reference. Alejandro does your gbib handle this also? Yes, in one sense: It can send commands to lyx but can't hear the answer. In practice, that's not very important. We're currently keeping 1.0 STL-free. I'd prefer to leave it unsorted since the user is likely to have sorted their .bib file (but I said that last time too). Yes, if you use several huge databases, better use an external bibtex browser. OK, I'll look for my patch and send it to Roland as soon as possible. Alejandro
Re: better BibTeX support
On Mit, 14 Apr 1999 Allan Rae wrote: >On Thu, 19 May 2135, Jochen Kuepper wrote: >> - sort the entries alphabetically. >> By taking a quick look at the sources this might be probably something for >> 1.1, when it uses a vector< string >, so you can just stable_sort that :-) > >If you use barracuda it will sort your .bib file for you in whatever order >you wish including alphabetically. So rather than force any particular >sort order on the keys I'd suggest we let the user sort their .bib file to >suit their tastes and that way they might be able to navigate better. Well, the problem is I have several distinct databases. Each of this is sorted like I want it, but in the CombBox inside LyX the entries are put behind each other - first all keys from database 1, then 2, ... . Yes, I agree using barracuda is more advanced, just thought it would be nice. I actually "copied" the LyX code to KLyX, but there I just sort all entries into the Combo. I don´t know what container to use, if there's something like STL vector (tell me what to use) I can use in LyX-1.0 I would send in a patch. Greetings, Jochen --- Jochen Küpper Heinrich-Heine-Universität Düsseldorf [EMAIL PROTECTED] Institut für Physikalische Chemie I Universitätsstr. 1, Geb 26.43 Raum 02.29 phone ++49-211-8113681 40225 Düsseldorf fax ++49-211-8115195 Germany http://www-public.rz.uni-duesseldorf.de/~jochen ---
Re: better BibTeX support
On Wed, 14 Apr 1999 14:09:33 +1000 (GMT+1000), Allan Rae wrote: >> > Arnd> Yes, please make the forms bigger! The German po-file is great, >[...] >> > Making the forms bigger would create problems for systems with low >> > resolution... We can't please everybody. The real solution would be to >> > have a layout manager for xforms popups (or rather a real toolkit). >> >> Right, but the citation form specifically is quite small, so it shouldn't be >> a problem to make it, say, the same size as the reference window. > >Either that or use shorter keys ;P > >Or do the labels on the form get truncated as well? Yes, especially if you have two labels in a single line, only the first one is shown. Without looking at the english version you never will know they exist: This really is LyXing for initiated. I'm sure it's what you all are aiming at. :) Cheers, Arnd
Re: better BibTeX support
On Thu, 15 Apr 1999, Allan Rae wrote: > In this case I'd prefer to have a marker or a label in the combox > separating the different databases. Sorting them would obviously disrupt > the order. I suppose it's a matter of how we each use the combox. That > is, do we remember the keys we need or do we look them up in a > bib-browser and then find them in the combox. If the latter is the case > then we'd be much better off with a bib-browser that could insert the > citation using the LyXServer. Yes, the combox can't be used in place of a bibtex browser. > Alejandro had a patch for barracuda to do this (it might even be in the > contrib directory). It should be somewhere, I remember I posted it years ago. I'll look for it but it's not hard to add this support to barracuda, using the lyxserver examples as a reference. > Alejandro does your gbib handle this also? Yes, in one sense: It can send commands to lyx but can't hear the answer. In practice, that's not very important. > We're currently keeping 1.0 STL-free. I'd prefer to leave it unsorted > since the user is likely to have sorted their .bib file (but I said that > last time too). Yes, if you use several huge databases, better use an external bibtex browser. OK, I'll look for my patch and send it to Roland as soon as possible. Alejandro
Re: better BibTeX support
On Thu, 19 May 2135 21:33:55 +0200, Jochen Kuepper wrote: Two suggestions regarding the bibtex-entry-key-combobox (hey, I am German, we are used to use words two lines long, or so): - make it bigger Well, it would make live much easier to show approx 10 entries or so, and also make it wide enough to show the full keys - or probably just 1.5 times as wide as it is right now. Sorry, I won t get into XForms any more, but probably it's quite easy for one of you guys. Yes, please make the forms bigger! The German po-file is great, but: It's German. This means, words normally are twice as long long as in other more decent languages (except, e. g. gaelic). So you cannot read many of the form entries in German and resizing with the window manager often does not work either. A special german form template would mean too much work, wouldn't it? Greets, Arnd
Re: better BibTeX support
"Arnd" == Arnd Hanses [EMAIL PROTECTED] writes: Arnd On Thu, 19 May 2135 21:33:55 +0200, Jochen Kuepper wrote: Two suggestions regarding the bibtex-entry-key-combobox (hey, I am German, we are used to use words two lines long, or so): - make it bigger Well, it would make live much easier to show approx 10 entries or so, and also make it wide enough to show the full keys - or probably just 1.5 times as wide as it is right now. Sorry, I won t get into XForms any more, but probably it's quite easy for one of you guys. Arnd Yes, please make the forms bigger! The German po-file is great, Arnd but: It's German. This means, words normally are twice as long Arnd long as in other more decent languages (except, Arnd e. g. gaelic). So you cannot read many of the form entries in Arnd German and resizing with the window manager often does not work Arnd either. A special german form template would mean too much work, Arnd wouldn't it? Making the forms bigger would create problems for systems with low resolution... We can't please everybody. The real solution would be to have a layout manager for xforms popups (or rather a real toolkit). JMarc
Re: better BibTeX support
On Tue, Apr 13, 1999 at 03:34:55PM +0200, Jean-Marc Lasgouttes wrote: "Arnd" == Arnd Hanses [EMAIL PROTECTED] writes: Arnd On Thu, 19 May 2135 21:33:55 +0200, Jochen Kuepper wrote: Two suggestions regarding the bibtex-entry-key-combobox (hey, I am German, we are used to use words two lines long, or so): - make it bigger Well, it would make live much easier to show approx 10 entries or so, and also make it wide enough to show the full keys - or probably just 1.5 times as wide as it is right now. Sorry, I won t get into XForms any more, but probably it's quite easy for one of you guys. Arnd Yes, please make the forms bigger! The German po-file is great, Arnd but: It's German. This means, words normally are twice as long Arnd long as in other more decent languages (except, Arnd e. g. gaelic). So you cannot read many of the form entries in Arnd German and resizing with the window manager often does not work Arnd either. A special german form template would mean too much work, Arnd wouldn't it? Making the forms bigger would create problems for systems with low resolution... We can't please everybody. The real solution would be to have a layout manager for xforms popups (or rather a real toolkit). Right, but the citation form specifically is quite small, so it shouldn't be a problem to make it, say, the same size as the reference window. -Amir
Re: better BibTeX support
On Tue, 13 Apr 1999, Amir Karger wrote: On Tue, Apr 13, 1999 at 03:34:55PM +0200, Jean-Marc Lasgouttes wrote: "Arnd" == Arnd Hanses [EMAIL PROTECTED] writes: Arnd On Thu, 19 May 2135 21:33:55 +0200, Jochen Kuepper wrote: Two suggestions regarding the bibtex-entry-key-combobox (hey, I am German, we are used to use words two lines long, or so): - make it bigger Well, it would make live much easier to show approx 10 entries or so, and also make it wide enough to show the full keys - or probably just 1.5 times as wide as it is right now. Sorry, I won t get into XForms any more, but probably it's quite easy for one of you guys. Just how long are these keys you are using? The combox is about 20 characters wide and admittedly a comma separated list in the text input field will require scrolling but its still visible. That reminds me, Alejandro it would still be handy to scan the actual bibitem insets in a file for the case of comma separated lists. Which is another problem we need to figure out for 1.1 -- how to provide the combox and allow appending of multiple citations in a single citation inset. Arnd Yes, please make the forms bigger! The German po-file is great, [...] Making the forms bigger would create problems for systems with low resolution... We can't please everybody. The real solution would be to have a layout manager for xforms popups (or rather a real toolkit). Right, but the citation form specifically is quite small, so it shouldn't be a problem to make it, say, the same size as the reference window. Either that or use shorter keys ;P Or do the labels on the form get truncated as well? Allan. (ARRae)
Re: better BibTeX support
On Thu, 19 May 2135, Jochen Kuepper wrote: - sort the entries alphabetically. By taking a quick look at the sources this might be probably something for 1.1, when it uses a vector string , so you can just stable_sort that :-) If you use barracuda it will sort your .bib file for you in whatever order you wish including alphabetically. So rather than force any particular sort order on the keys I'd suggest we let the user sort their .bib file to suit their tastes and that way they might be able to navigate better. Allan. (ARRae)
Re: better BibTeX support
On Wed, 14 Apr 1999, Allan Rae wrote: That reminds me, Alejandro it would still be handy to scan the actual bibitem insets in a file for the case of comma separated lists. Which is another problem we need to figure out for 1.1 -- how to provide the combox and allow appending of multiple citations in a single citation inset. Easy, allowing multiple selection in the combox. Alejandro
Re: better BibTeX support
On Thu, 19 May 2135 21:33:55 +0200, Jochen Kuepper wrote: >Two suggestions regarding the bibtex-entry-key-combobox (hey, I am German, we >are used to use words two lines long, or so): > >- make it bigger > Well, it would make live much easier to show approx 10 entries or so, and > also make it wide enough to show the full keys - or probably just 1.5 times > as wide as it is right now. > Sorry, I won t get into XForms any more, but probably it's quite easy for one > of you guys. Yes, please make the forms bigger! The German po-file is great, but: It's German. This means, words normally are twice as long long as in other more decent languages (except, e. g. gaelic). So you cannot read many of the form entries in German and resizing with the window manager often does not work either. A special german form template would mean too much work, wouldn't it? Greets, Arnd
Re: better BibTeX support
> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes: Arnd> On Thu, 19 May 2135 21:33:55 +0200, Jochen Kuepper wrote: >> Two suggestions regarding the bibtex-entry-key-combobox (hey, I am >> German, we are used to use words two lines long, or so): >> >> - make it bigger Well, it would make live much easier to show >> approx 10 entries or so, and also make it wide enough to show the >> full keys - or probably just 1.5 times as wide as it is right now. >> Sorry, I won t get into XForms any more, but probably it's quite >> easy for one of you guys. Arnd> Yes, please make the forms bigger! The German po-file is great, Arnd> but: It's German. This means, words normally are twice as long Arnd> long as in other more decent languages (except, Arnd> e. g. gaelic). So you cannot read many of the form entries in Arnd> German and resizing with the window manager often does not work Arnd> either. A special german form template would mean too much work, Arnd> wouldn't it? Making the forms bigger would create problems for systems with low resolution... We can't please everybody. The real solution would be to have a layout manager for xforms popups (or rather a real toolkit). JMarc
Re: better BibTeX support
On Tue, Apr 13, 1999 at 03:34:55PM +0200, Jean-Marc Lasgouttes wrote: > > "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes: > > Arnd> On Thu, 19 May 2135 21:33:55 +0200, Jochen Kuepper wrote: > > >> Two suggestions regarding the bibtex-entry-key-combobox (hey, I am > >> German, we are used to use words two lines long, or so): > >> > >> - make it bigger Well, it would make live much easier to show > >> approx 10 entries or so, and also make it wide enough to show the > >> full keys - or probably just 1.5 times as wide as it is right now. > >> Sorry, I won t get into XForms any more, but probably it's quite > >> easy for one of you guys. > > Arnd> Yes, please make the forms bigger! The German po-file is great, > Arnd> but: It's German. This means, words normally are twice as long > Arnd> long as in other more decent languages (except, > Arnd> e. g. gaelic). So you cannot read many of the form entries in > Arnd> German and resizing with the window manager often does not work > Arnd> either. A special german form template would mean too much work, > Arnd> wouldn't it? > > Making the forms bigger would create problems for systems with low > resolution... We can't please everybody. The real solution would be to > have a layout manager for xforms popups (or rather a real toolkit). Right, but the citation form specifically is quite small, so it shouldn't be a problem to make it, say, the same size as the reference window. -Amir
Re: better BibTeX support
On Tue, 13 Apr 1999, Amir Karger wrote: > On Tue, Apr 13, 1999 at 03:34:55PM +0200, Jean-Marc Lasgouttes wrote: > > > "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes: > > > > Arnd> On Thu, 19 May 2135 21:33:55 +0200, Jochen Kuepper wrote: > > > > >> Two suggestions regarding the bibtex-entry-key-combobox (hey, I am > > >> German, we are used to use words two lines long, or so): > > >> > > >> - make it bigger Well, it would make live much easier to show > > >> approx 10 entries or so, and also make it wide enough to show the > > >> full keys - or probably just 1.5 times as wide as it is right now. > > >> Sorry, I won t get into XForms any more, but probably it's quite > > >> easy for one of you guys. Just how long are these keys you are using? The combox is about 20 characters wide and admittedly a comma separated list in the text input field will require scrolling but its still visible. That reminds me, Alejandro it would still be handy to scan the actual bibitem insets in a file for the case of comma separated lists. Which is another problem we need to figure out for 1.1 -- how to provide the combox and allow appending of multiple citations in a single citation inset. > > > > Arnd> Yes, please make the forms bigger! The German po-file is great, [...] > > Making the forms bigger would create problems for systems with low > > resolution... We can't please everybody. The real solution would be to > > have a layout manager for xforms popups (or rather a real toolkit). > > Right, but the citation form specifically is quite small, so it shouldn't be > a problem to make it, say, the same size as the reference window. Either that or use shorter keys ;P Or do the labels on the form get truncated as well? Allan. (ARRae)
Re: better BibTeX support
On Thu, 19 May 2135, Jochen Kuepper wrote: > - sort the entries alphabetically. > By taking a quick look at the sources this might be probably something for > 1.1, when it uses a vector< string >, so you can just stable_sort that :-) If you use barracuda it will sort your .bib file for you in whatever order you wish including alphabetically. So rather than force any particular sort order on the keys I'd suggest we let the user sort their .bib file to suit their tastes and that way they might be able to navigate better. Allan. (ARRae)
Re: better BibTeX support
On Wed, 14 Apr 1999, Allan Rae wrote: > That reminds me, Alejandro it would still be handy to scan the actual > bibitem insets in a file for the case of comma separated lists. Which is > another problem we need to figure out for 1.1 -- how to provide the combox > and allow appending of multiple citations in a single citation inset. Easy, allowing multiple selection in the combox. Alejandro
Re: Better Bibtex-support
miyata writes:
m I wrote:
[EMAIL PROTECTED] (Lars Gullik Bjnes) wrote:
Cant't we just do this: tmp =
FileOpenSearch(getenv("BIBINPUTS"),tmp,"bib"); if (tmp.empty())
tmp = FileOpenSearch(getEnvPath("BIBINPUT"), tmp, "bib");
And just don't care if it is EMX or not.
Yes, IMO, we can.
m No, No, No! It is *UNIX* on which getEnvPath() is required, not
m on OS/2.
that getenv was a typo.
The code now looks like:
tmp = FileOpenSearch(getEnvPath("BIBINPUTS"),tmp,"bib");
if (tmp.empty())
tmp = FileOpenSearch(getEnvPath("BIBINPUT"),
tmp, "bib");
Is that ok?
Lgb
Re: Better Bibtex-support
>> miyata writes:
m> I wrote:
>> [EMAIL PROTECTED] (Lars Gullik Bjnes) wrote:
>>
>> > Cant't we just do this: > > tmp =
>> FileOpenSearch(getenv("BIBINPUTS"),tmp,"bib"); > if (tmp.empty())
>> > tmp = FileOpenSearch(getEnvPath("BIBINPUT"), tmp, "bib"); > >
>> And just don't care if it is EMX or not.
>>
>> Yes, IMO, we can.
m> No, No, No! It is *UNIX* on which getEnvPath() is required, not
m> on OS/2.
that getenv was a typo.
The code now looks like:
tmp = FileOpenSearch(getEnvPath("BIBINPUTS"),tmp,"bib");
if (tmp.empty())
tmp = FileOpenSearch(getEnvPath("BIBINPUT"),
tmp, "bib");
Is that ok?
Lgb
Re: Better Bibtex-support
I wrote:
[EMAIL PROTECTED] (Lars Gullik Bjnes) wrote:
Cant't we just do this:
tmp = FileOpenSearch(getenv("BIBINPUTS"),tmp,"bib");
if (tmp.empty())
tmp = FileOpenSearch(getEnvPath("BIBINPUT"), tmp, "bib");
And just don't care if it is EMX or not.
Yes, IMO, we can.
No, No, No! It is *UNIX* on which getEnvPath() is required,
not on OS/2.
Regards,
SMiyata
Re: Better Bibtex-support
I wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjnes) wrote:
>
> > Cant't we just do this:
> >
> > tmp = FileOpenSearch(getenv("BIBINPUTS"),tmp,"bib");
> > if (tmp.empty())
> > tmp = FileOpenSearch(getEnvPath("BIBINPUT"), tmp, "bib");
> >
> > And just don't care if it is EMX or not.
>
> Yes, IMO, we can.
No, No, No! It is *UNIX* on which getEnvPath() is required,
not on OS/2.
Regards,
SMiyata
Re: Better Bibtex-support
Alejandro Aguilar Sierra writes: AAS What do the others think? Any objection to include it to 1.0.2? To me it looked rather clean, so if tested and deemed "bugless" we shoulc include it. For 1.1.x some things should be rewritten to use ANSI C++. f.ex. string::getline instead of reading single chars with fgetc. So, put it into CVS so that it will be included in the prerelease. Lgb
Re: Better Bibtex-support
>> Alejandro Aguilar Sierra writes: AAS> What do the others think? Any objection to include it to 1.0.2? To me it looked rather clean, so if tested and deemed "bugless" we shoulc include it. For 1.1.x some things should be rewritten to use ANSI C++. f.ex. string::getline instead of reading single chars with fgetc. So, put it into CVS so that it will be included in the prerelease. Lgb
Re: Better Bibtex-support
Alejandro Aguilar Sierra wrote:
Could you please send the patch so we can evaluate whether it could be
incorporated to 1.0.2?
Here it is!
I should add that I have more experience programming in C, than in C++
so you are welcome to have a look at the code.
The code adds a method to the InsetBibtex class that can be used to
retrieve the keys from the corresponding bibtex databases. It implements
a very simple bibtex parser, that simply scans the file for lines
beginning with @, and then parses that line.
Every time the Citation pop up is opened this new method in InsetBibtex
is called and the keys inserted in the combobox. This may seem like a
waste, but it is the best method I can think of now and it allows you to
edit the bibtex file and see the changes reflected in the keys listed
immediately. On a Pentium 100 notebook it is not a perfomance problem,
even with a big annotated bibtex file of about 100 K.
I have chosen to let the code fail silently, if the file can't be found.
That means, you can type your text and insert references, even if your
bibtex file is not present (e.g. on a notebook).
One last thing: The code searches for bibtex files in the same directory
as the lyx file and then in the directories listed in the BIBINPUTS
environment variable. It does NOT search in the standard texmf-tree, so
if your bibtex files are there, you will have to add the path to
BIBINPUTS.
I think that's all. Have a look at the code and see if you can use it.
Greetings
Jesper
Index: lyx-1_0_x/src/insetbib.C
===
RCS file: /usr/local/lyxsrc/cvsroot/lyx-1_0_x/src/insetbib.C,v
retrieving revision 1.6
diff -u -r1.6 insetbib.C
--- insetbib.C 1999/02/24 04:35:25 1.6
+++ insetbib.C 1999/04/05 07:59:44
@@ -368,6 +368,64 @@
return 2;
}
+// This method returns a comma separated list of Bibtex entries
+LString InsetBibtex::getKeys() const
+{
+ // This hack is copied from InsetBibtex::Latex.
+ // Is it still needed?
+ if (!owner) {
+ owner = current_view-currentBuffer();
+ }
+
+ // We need to create absolute path names for bibliographies
+ // First look for bib-file in same directory as document,
+ // then in all directories listed in environment variable
+ // BIBINPUTS
+ LString bibfiles, linebuf, tmp, keys;
+ bibfiles = getContents();
+ bibfiles.split(tmp, ',');
+ while(!tmp.empty()) {
+ if (IsFileReadable(MakeAbsPath(tmp,owner-filepath)+".bib"))
+ tmp = MakeAbsPath(tmp,owner-filepath)+".bib";
+ else
+ tmp = FileOpenSearch(getenv("BIBINPUTS"),tmp,"bib");
+
+ // If we didn't find a matching file name just fail silently
+ if (!tmp.empty()) {
+
+ // This is a _very_ simple parser for Bibtex database files.
+ // All it does is to look for lines starting in @ and not
+ // being @preamble and @string entries.
+ // It does NOT do any syntax checking!
+ FilePtr file(tmp,FilePtr::read);
+ char c;
+
+ while (! feof(file)) {
+ c = fgetc(file);
+
+ // At end of each line check if line begins with '@'
+ if ( c == '\n') {
+ if ( linebuf.prefixIs("@") ) {
+ linebuf.subst('{','(');
+ linebuf.split(tmp,'(');
+ tmp.lowercase();
+ if ( ! tmp.prefixIs("@string")
+!tmp.prefixIs("@preamble") ) {
+ linebuf.split(tmp,',');
+ if (!tmp.empty())
+ keys +=tmp.strip()+",";
+ }
+ }
+ linebuf.clean();
+ } else {
+ linebuf += c;
+ }
+ }
+ }
+ // Get next file name
+ bibfiles.split(tmp, ',');
+ }
+ return keys;
+}
// BibTeX should have its own dialog. This is provisional.
void InsetBibtex::Edit(int, int)
@@ -439,29 +497,34 @@
}
if (combox-empty()) {
- // might be using bibtex instead.
- // Hmmm... how can I be sure?? ARRae
+ // Might be using bibtex instead.
+ // Search for Bibtex inset
par = current_view-currentBuffer()-paragraph;
while (par) {
-
Re: Better Bibtex-support
On Mon, 5 Apr 1999, Jesper Overgaard wrote: The code adds a method to the InsetBibtex class that can be used to retrieve the keys from the corresponding bibtex databases. It implements a very simple bibtex parser, that simply scans the file for lines beginning with @, and then parses that line. Every time the Citation pop up is opened this new method in InsetBibtex is called and the keys inserted in the combobox. This may seem like a waste, but it is the best method I can think of now and it allows you to edit the bibtex file and see the changes reflected in the keys listed immediately. On a Pentium 100 notebook it is not a perfomance problem, even with a big annotated bibtex file of about 100 K. I applied it to my local version, almost blindly, and it works fine. IMO it could be included since it's a useful feature, and doesn't seem to have anything harmful, but I'll check it more carefully. However I don't think it will be useful for people that use huge databases. Those still can use an external bibtex browser conected to lyx by the lyx server. What do the others think? Any objection to include it to 1.0.2? Alejandro
Re: Better Bibtex-support
Alejandro Aguilar Sierra wrote:
> Could you please send the patch so we can evaluate whether it could be
> incorporated to 1.0.2?
Here it is!
I should add that I have more experience programming in C, than in C++
so you are welcome to have a look at the code.
The code adds a method to the InsetBibtex class that can be used to
retrieve the keys from the corresponding bibtex databases. It implements
a very simple bibtex parser, that simply scans the file for lines
beginning with @, and then parses that line.
Every time the Citation pop up is opened this new method in InsetBibtex
is called and the keys inserted in the combobox. This may seem like a
waste, but it is the best method I can think of now and it allows you to
edit the bibtex file and see the changes reflected in the keys listed
immediately. On a Pentium 100 notebook it is not a perfomance problem,
even with a big annotated bibtex file of about 100 K.
I have chosen to let the code fail silently, if the file can't be found.
That means, you can type your text and insert references, even if your
bibtex file is not present (e.g. on a notebook).
One last thing: The code searches for bibtex files in the same directory
as the lyx file and then in the directories listed in the BIBINPUTS
environment variable. It does NOT search in the standard texmf-tree, so
if your bibtex files are there, you will have to add the path to
BIBINPUTS.
I think that's all. Have a look at the code and see if you can use it.
Greetings
Jesper
Index: lyx-1_0_x/src/insetbib.C
===
RCS file: /usr/local/lyxsrc/cvsroot/lyx-1_0_x/src/insetbib.C,v
retrieving revision 1.6
diff -u -r1.6 insetbib.C
--- insetbib.C 1999/02/24 04:35:25 1.6
+++ insetbib.C 1999/04/05 07:59:44
@@ -368,6 +368,64 @@
return 2;
}
+// This method returns a comma separated list of Bibtex entries
+LString InsetBibtex::getKeys() const
+{
+ // This hack is copied from InsetBibtex::Latex.
+ // Is it still needed?
+ if (!owner) {
+ owner = current_view->currentBuffer();
+ }
+
+ // We need to create absolute path names for bibliographies
+ // First look for bib-file in same directory as document,
+ // then in all directories listed in environment variable
+ // BIBINPUTS
+ LString bibfiles, linebuf, tmp, keys;
+ bibfiles = getContents();
+ bibfiles.split(tmp, ',');
+ while(!tmp.empty()) {
+ if (IsFileReadable(MakeAbsPath(tmp,owner->filepath)+".bib"))
+ tmp = MakeAbsPath(tmp,owner->filepath)+".bib";
+ else
+ tmp = FileOpenSearch(getenv("BIBINPUTS"),tmp,"bib");
+
+ // If we didn't find a matching file name just fail silently
+ if (!tmp.empty()) {
+
+ // This is a _very_ simple parser for Bibtex database files.
+ // All it does is to look for lines starting in @ and not
+ // being @preamble and @string entries.
+ // It does NOT do any syntax checking!
+ FilePtr file(tmp,FilePtr::read);
+ char c;
+
+ while (! feof(file)) {
+ c = fgetc(file);
+
+ // At end of each line check if line begins with '@'
+ if ( c == '\n') {
+ if ( linebuf.prefixIs("@") ) {
+ linebuf.subst('{','(');
+ linebuf.split(tmp,'(');
+ tmp.lowercase();
+ if ( ! tmp.prefixIs("@string") &&
+!tmp.prefixIs("@preamble") ) {
+ linebuf.split(tmp,',');
+ if (!tmp.empty())
+ keys +=tmp.strip()+",";
+ }
+ }
+ linebuf.clean();
+ } else {
+ linebuf += c;
+ }
+ }
+ }
+ // Get next file name
+ bibfiles.split(tmp, ',');
+ }
+ return keys;
+}
// BibTeX should have its own dialog. This is provisional.
void InsetBibtex::Edit(int, int)
@@ -439,29 +497,34 @@
}
if (combox->empty()) {
- // might be using bibtex instead.
- // Hmmm... how can I be sure?? ARRae
+ // Might be using bibtex instead.
+ // Search for Bibtex inset
par = current_view->currentBuffer()->paragraph;
while
Re: Better Bibtex-support
On Mon, 5 Apr 1999, Jesper Overgaard wrote: > The code adds a method to the InsetBibtex class that can be used to > retrieve the keys from the corresponding bibtex databases. It implements > a very simple bibtex parser, that simply scans the file for lines > beginning with @, and then parses that line. > > Every time the Citation pop up is opened this new method in InsetBibtex > is called and the keys inserted in the combobox. This may seem like a > waste, but it is the best method I can think of now and it allows you to > edit the bibtex file and see the changes reflected in the keys listed > immediately. On a Pentium 100 notebook it is not a perfomance problem, > even with a big annotated bibtex file of about 100 K. I applied it to my local version, almost blindly, and it works fine. IMO it could be included since it's a useful feature, and doesn't seem to have anything harmful, but I'll check it more carefully. However I don't think it will be useful for people that use huge databases. Those still can use an external bibtex browser conected to lyx by the lyx server. What do the others think? Any objection to include it to 1.0.2? Alejandro
