Dekel> I'm not sure that @string expansion is a feature that worth the effort
Dekel> of coding it (I listed more important features (IMHO) below).
Perhaps not for now. I have some ideas for adding entries to the BibTeX
database, in which case the parser will need to be a little more clever.
Dekel> Since InsetBibtex::getKeys() operates on the entire bibliography
Dekel> database, which can be quite large, it might be better to do there as
Dekel> little work as possible, and do the parsing in InsetCitation::Edit().
Indeed. At the moment, the database gets parsed every time a new citation dialog
is opened. Clearly this is stupid. I think something better would be to have a
class containing the database. Let's call it Biblio.
Biblio would contain a list of database files, getting this information from
the InsetBibtex dialog and a vector of database entries from these files.
The buffer would contain some data Biblio bib which could be used in
InsetCitation::Edit() something like:
if( current_view->buffer().bib.modified() ) {
current_view->buffer().bib.update();
bibkeys_info = current_view->buffer().bib.get();
bibkeys.clear();
for (unsigned int i = 0; i < bibkeys_info.size(); ++i)
bibkeys.push_back(bibkeys_info[i].first);
Update (citation_form->bibBrsr, citation_form->addBtn, bibkeys);
}
Biblio::modified() would check each file of the database to see whether they
had been changed since the last Biblio::update() or initialisation.
Biblio::update() would update that part of the database associated with a
particular (recently modified) file.
In addition to Biblio::get(), the class could (eventually) have a method
Biblio::set() that popped up some new dialog and allowed new entries to be
input into the database.
If people like the general idea, then I'll put some effort into thinking about
the specifics.
Dekel> For example, instead of returning vector<string,string> from
Dekel> insetbib::getKeys(), where the first element in a pair is a key, and
Dekel> the second is the concatenation of the lines in the entry strings,
Dekel> return vector<string,vector<string>>, where the second element of the
Dekel> pair is a vector of the lines.
I think that the second entry should actually be a vector<pair<string,string>>
itself. That is, insetbib::getKeys() returns
vector<pair<string,vector<pair<string,string>>>>
I know this is a mouthful, but each database entry would then contain a key
(the first string) together with a vector<pair<string,string>> of BibTeX
fields. Things like "author", "Jo Bloggs and Uncle Sam".
Alternatively, using my concept of a Biblio class, this could be split up into
manageable get() functions. Perhaps Biblio::getKeys() returning just the keys
as a vector<string> and Biblio::getKeyFields( int no ) returning the BiBTeX
fields to a particular key as a vector<pair<string,string>>.
Dekel> Below the browser line, add a text input form, and a button labeled
Dekel> search. When pressing the button, a key that its bibliography entry
Dekel> contains that string is searched for, and if such a key is found it will
Dekel> be selected in the bibliography keys browser (if there is already a
Dekel> selected key in this browser, the search will start from the next key).
OK. So the Citation dialog would call a function in the Biblio class that could
search its database.
Dekel> Add a toggle button named "sort" below the bibliography keys browser,
Dekel> that allows you to watch the keys in sorted order/original order.
Don't understand the value of this. Perhaps getKeys() should always return a
sorted vector. However, it would again be easy to do as you desire if we had a
Biblio storage class.
Dekel> Move up/down buttons for reordering the keys in the inset-keys browser.
No. This is LaTeX functionality. If you want sorted keys, then use the cite
package (or natbib, eventually).
Dekel> Discard "static vector<string> bibkeys;" . This requires deleting the
Dekel> InsetCitation::Update() method, and also adding a functor for using with
Dekel> std::find.
Again, I don't see the value of this. Do you mean chuck out the bibliography
browser?
Finally, an additional word in favor of a database class Biblio. It would be
independant of the particular GUI and could be accessed by all three of today's
InsetCitation, InsetBibKey and InsetBibtex. I recognise that more thought is
needed here, but the more I think about it, the more I like my suggestion!
Someone bring me back down to Earth!
Angus
