Use the function support:truncateWithEllipsis() to shorten a docstring with
... at the end. Actually we use U+2026 HORIZONTAL ELLIPSIS instead of "..." when
automatically shortening strings. This is to be consistent with Qt's own
truncation and is much nicer on the screen.
This includes the bugs #9575 and #9572 regarding broken text elision in the
outliner.
Known issues (non-regressions):
* TocBackend::updateItem() should be rewritten to update all TOCs. (#8386)
* "..." should be replaced with … everywhere else on the interface (including
translation strings).
* We should prefer to rely on QFontMetrics::elidedText() to truncate strings
with an ellipsis whenever possible, or an equivalent for the buffer view
dependent on the font metrics. See the warning in src/support/lstrings.h.
We introduce TocBuilder for building TOCs that take into account both float
insets and their captions.
* Floats without caption are shown with their content.
* Floats with a caption are shown with their caption, but clicking the entry now
correctly moves to the float and not to the caption.
* Subsequent captions produce additional entries in the TOC.
* Figures and subfigures are correctly ordered in the outliner.
* New TOC "senseless" for captions appearing alone (a bit like broken references
are still displayed in the menu and outliner).
* Disable LFUN_CAPTION_INSERT if there is already a caption in a listing
Known issues:
* Inconsistent output for includes located inside floats
* We should record the end of the float in addition of the beginning for a more
accurate cursor -> outliner entry conversion
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
for possible thread conflicts, of the sort Georg resolved at
6a30211f. I have made static variables const where possible,
and marked cases that looked potentially problematic with the
comment:
// FIXME THREAD
Many of these definitely are vulnerable to concurrent access, such
as the static variables declared at the start of output_latex.cpp.
Suppose, e.g., we were outputting latex and also displaying the
source of a different document.
I'd appreciate it if others could grep for "FIXME THREAD" and see
if some of these are harmless, or what.
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.
The default citation capability of LaTeX is not a true numerical
citation engine, rather it uses a mixture of labels/numbers. Thus
we now distinguish them: "numerical" always increments the bibitem
counter and uses its value as a numerical citation label, while
"default" only uses the bibitem counter when no label is provided.
LyX file format incremented to 471.
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?
output, due to failure to clean the ids in the new citation stuff.
I've solved this by allowing the citation format information to contain
keys of the form "clean:key". This signals that we are to apply the
html::cleanAttr() function to the key before returning it. I.e., we
strip non-alphanumeric stuff, basically.
This only move the code, but does not change the displayed labels.
Thus for numerical citation, the label is set to the cite number;
for author-year citation, the abbreviated list of authors is used
i.e. "Smith et al. 2001".
Eventually, we might want to make the label customizable, or get
it from BibTeX.
What was previously accomplished by wrapCitation is now customizable in the
layout files. What we provide by default here corresponds roughly to the
LyX 2.0 behavior.
Math commands need it as well as text commands. At the same time, this
further unifies the checking for termination and fixes cases of wrong
output (e.g. for 0x2005).
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
now) and move more packages to the new exclude mechanism.
The remaining ones are not so easy.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40442 a592a061-630c-0410-9148-cb99ea01b6c8
Fix a bug introduced in r26547. Also reorders the entries for
natbib-numerical into a more natural, visually pleasing order.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39777 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
