This entails a change of getAbbrAuthor to getAuthorList (the default is
still abbreviated with respect to MaxCiteItems, but the list can be, at
explicit request, shortened or full notwithstanding MaxCiteItems.
Next to the cmd name, introduce optional latex names (that might differ
from the cmd name) and aliases (that are "obsoleted by" the cmd).
This enhances portability between the engines.
In addition to the classic crossref, biblatex introduces xdata
references in order to source-out common data of entries. Entries
that have "xdata = {somekey}" just inherit all fields from the
respective @xdata entry, if the field is not already defined in
the entry itself (just like crossref, with the exception that @xdata
entries themselves are _never_ output on their own). @xdata entries can
themselves inherit to other @xdata entries (ad infinitum). So you can,
for instance, setup an xdata entry for a book series with series name
that inherits an xdata entry with information of the publisher
(publisher, address). Any book of that series would just need to refer
to the series xdata and add the number.
BiblioInfo now checks, in addition to crossrefs, for such xdata
references and inherits missing fields.
Nte that biblatex also introduces an "xref" field as an alternative to
crossref. We must not care about that, since the point of xref is that
it does not inherit fields from the target (just cites that one if a
given number of refs to it exist)
was not English: We return the the abbreviated author "One and Two",
but translated to the GUI language; then we search that for " and "
in order to pull the authors apart again.
I've just replaced the distinct routines with a single one that handles
both cases, depending upon whether a Buffer is provided as one argument.
The firs tinvolves a thinko in BibTeXInfo::expandFormat. We were previously
counting passes through this routine, which means: one for every character,
more or less. So long strings would hit the "recursion limit". But what
we are worried about is an infinite loop caused by misues of macros, so that
is what we need to count.
This prevents the error we were previously getting, but it reveals a huge
slowdown when one tries to open a citation inset with a large nubmer of keys.
So we also limit the number of keys we try to process, and the length of the
string we try to display, when we are generating citation information.
I'm convinced that there is a deeper problem in how citation information is
generated (see the bug tracker for more info), but that will require major
surgery and a file format change
The problem is caused by the fact that Encodings::fromLaTeXCommand
is very slow. It's not clear to me if that can be fixed, or if that
is just how things are. Georg suggested another time that we might
use tex2lyx in or instead of convertLatexCommands() in BiblioInfo.cpp,
but I don't know if that would much faster. The author string in the
example file is 32K characters long. As long as some files tex2lyx
would convert.
Add a new layout syntax CiteEngine to define the citation commands
available for a given citation engine.
Also extend the CiteFormat syntax to allow more customization. This
mechanism, previously used to produce bibliography entries in the
citation GUI based on the BibTeX entrytype, is now also used to
produce the textual labels for citation insets in the buffer view.
Thus citation styles are almost completely customizable by modules.
Modules for the basic, jurabib and natbib engines are implemented.
Layout format incremented to 37.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40820 a592a061-630c-0410-9148-cb99ea01b6c8
To avoid duplicity, remove natbib_authoryear and natbib_numerical
and replace them by natbib, and keep track of the engine `type'
in the new \cite_engine_type document setting. This will make it
easier to add more citation engines.
LyX format incremented to 424.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40592 a592a061-630c-0410-9148-cb99ea01b6c8
By the way, has anyone noticed that _() returns empty if you call it
on a string we don't know how to translate? Might it be better if it
returned the original string?
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33925 a592a061-630c-0410-9148-cb99ea01b6c8
allows for layout- or module-level customization of the display in the
citation dialog and of the XHTML bibliography output.
There is more of this to come, by the way. The next step is to allow
macros. That will make it easier to deal with translation issues, which
ought to be the final step.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33920 a592a061-630c-0410-9148-cb99ea01b6c8
entries are represented, both in LyX and in XHTML output. Try looking at
the InsetCitation dialog and, in particular, at entries that have
crossref fields and you will see the benefit there.
The next step is to allow this stuff to be read from a file.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33879 a592a061-630c-0410-9148-cb99ea01b6c8
There is now no reason not to use operator[] here, which is more natural.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@27635 a592a061-630c-0410-9148-cb99ea01b6c8
