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
Reason for this 'cleanup' is the strange "optional = false" lines at the
end of the "case md_item" and "case md_subitem". Then, it is nicer to
directly use the value of the switch to be the running variable and to use
this to determine whether an item is optional and whether we should quit.
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
We only need to sort the formats when it is really necessary, i.e. for GUI
purposes.
This also prevents 11000 requests for translation everytime the toolbars
are updated.
* some functionality is in new modules now
new header locations and library names: QtConcurrent and QtWidgets
* method setResizeMode is renamed to setSectionResizeMode
* deprecated QAbstractItemModel::reset() is dropped now
* platform specific code like QApplication::syncX() is not common anymore
* QString::fromAscii() is dropped now
* some QDesktopServices methods has been moved to QStandardPaths
This adds an optional 'set' argument to the language lfun and reintroduces toggling.
Additions by me reintroduce the possibility to reset to the document language via 'language reset' or just 'language'
While cppcheck did not turn out any suspicious error messages, using
the "performance" flag highlighted several nitpicks in three categories
* do not use it++ for iterators, ++it is better
* do not use size() to test for emptyness, empty() is here
* do not use "const T" as a function parameter, "const & T" is better
I doubt that any of these is a real performance problem, but the code is cleaner anyway.
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
Gcc 4.7 warns rightly about the questionalble practise of having different types in
the ?: operator. This patch fixes that.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40585 a592a061-630c-0410-9148-cb99ea01b6c8
under Document>Settings>Output.
It turns out that we always want this list to be sorted when we get it,
so we can sort it in BufferParams rather than in three different places.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40101 a592a061-630c-0410-9148-cb99ea01b6c8
