We are not capable of handling two bibitems within one biblio paragraph.
That's why we have functions like Paragraph::brokenBiblio() and
Paragraph::fixBiblio(). So, if we fix the biblio by deleting the second
bibitem, we should not keep it as deleted.
This code caused a crash because the inset was released, but still kept as
deleted.
Fixes-bug: #8646.
Move the cursor in front of a bibitem and press enter.
Paragraph::fixBiblio will insert a new bibitem without a font in the new
paragraph. This will make Paragraph::fontSpan assert because the fontlist_
of the new paragraph is empty.
Using "Font no_font" in case no font was supplied was wrong. Instantiating a font object without specifying the language lead to a font object having the default_language that is hardcoded to "english". See Language::read().
This caused that there were spurious language changes in the LaTeX output
and made some document uncompilable.
This reverts commit 3619954590.
Previously, an empty paragraph would always yield something like:
<div><a id='magicparid-35' /></div>
because we had no way to "defer" the anchor tag. Now this is wrapped
into the div, in effect, and we abandon it all if there's no content.
An iterator is typicall incremented passed the valid data into the 'end'
state. However, if this means that other functions are called with invalid
parameter, we should fix this.
This explains why fontSpan was called with pos==size() while this was not
expected to happen.
This patch reverts partly f5ad0c128a (Jean-Marc Lasgouttes; Get rid of
annoying warning message).
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?
need the master buffer here, too: in looking up fonts during XHTML
output.
I'm half tempted to pass the master buffer to these routines, though
there are times, I think, when we want the actual buffer: e.g., when
looking up branches.
work we do when calling plaintext() for the purpose of generating
material for the advanced search function.
Here again, not only were we parsing BibTeX files, since Julien's
(sensible) introduction of plaintext output for that inset, but we
were in fact writing (to disk) complete plaintext output for
included files every time we did such a search.
so we can write a limited amount when using this for TOC and
tooltip output.
This should solve the problem with slowness that Kornel noticed,
which was caused by our trying to write an entire plaintext
bibliography every time we updated the TOC. We did that because
he had a bibliography inside a branch, and we use plaintext for
creating the tooltip that goes with the branch list.
Other related bugs were fixed along the way. E.g., it turns out
that, if someone had an InsetInclude inside a branch, then we would
have been writing a *plaintext file* for that inset every time we
updated the TOC. I wonder if some of the other reports of slowness
we have received might be due to this kind of issue?
Fixes bug #7111: Assertion with undo and InsetBibitem
* add Paragraph::brokenBiblio(), with tells whether there is something to fix.
* rename Paragraph::checkBiblio to fixBiblio; simplify it greatly by using
InsetList methods
* In TextMetrics::redoParagraph, call recordUndo before fixBiblio (only when
there is something to fix obviously)
Special care is taken to update cursor only when it makes sense. Note
that there are cases where undo information is not recorded (current
cursor not in the slice where action happens)
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.
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).
* do not terminate macros by {} if not necessary (prevent kerning violation)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40891 a592a061-630c-0410-9148-cb99ea01b6c8
- Interpret argument of LFUN_SPACE_INSERT correctly
- Use InsetMathSpace instead of InsetMathSpecialChar for "\ " (bug # 7728)
- Use InsetMathSpace instead of InsetMathChar for ~ (bug # 7728).
This fixes also the display in LyX (previously a literal ~ was displayed).
Using InsetMathSpace enables also the "Insert Formatting" menu entries.
No file format change is needed, since the LaTeX export is unchanged.
Note that there are still some bugs related to spaces in math:
#7746, #7747, #7749, #7842
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39947 a592a061-630c-0410-9148-cb99ea01b6c8
throwing errors in the case where we are inside a charstyle that itself
uses a font tag, e.g., strong from the logical markup module. This at
least gets rid of most of the errors, and doesn't seem to cause any
other problems.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38220 a592a061-630c-0410-9148-cb99ea01b6c8
make NOBREAKDASH isLetter()
* Paragraph.cpp (isWord separator):
handle composites with hyphens as one word (i.e., "-" is not a word separator).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37946 a592a061-630c-0410-9148-cb99ea01b6c8
Currently, if an inset outputs a newline, the new latex row is still
associated with a previous id/pos. Now, if a latex error occurs before
this newline, we would still highlight everything associated to that
id/pos, even if it is extraneous to the error.
This is avoided by associating the new latex row with the id/pos in
effect right before entering the inset. If an inset does not output
a newline, it is not excluded from the selection, consistent with the
fact that the text of the inset does appear in the error description.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37903 a592a061-630c-0410-9148-cb99ea01b6c8
Note that View->Source now shows that a character cannot be encoded.
However, the error is still unreported due to bug #7324.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37791 a592a061-630c-0410-9148-cb99ea01b6c8
resetFontEdit(). The former is used for on-screen and export formatting,
and the latter is used for interactive editing.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37761 a592a061-630c-0410-9148-cb99ea01b6c8
a special phrase, simply export the segment as normal text. For other
uses of these methods, end_pos is -1, so the original behavior is unaltered.
This allows for finding properly the LyX, LaTeX and other special phrases
with Advanced Find, when ignore format is off.
This complements the other changes made to latex export methods, for
exporting to latex with a given final end position.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37599 a592a061-630c-0410-9148-cb99ea01b6c8
counting when exporting to latex. This is done for the code comprised
between \begin{document} and \end{document}, while the preamble code
still needs manual calls to TexRow::newline() for registering new lines.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37584 a592a061-630c-0410-9148-cb99ea01b6c8
blank lines may be inadvertently output. This is achieved by using two
special iomanip-like variables (breakln and safebreakln) in the lyx::
namespace. When they are inserted in the stream, a newline is output
only if not already at the beginning of a line. The difference between
breakln and safebreakln is that, if needed, the former outputs '\n'
and the latter "%\n".
In future, the new class will also be used for counting the number of
newlines issued. Even if the infractrure for doing that is already in
place, the counting is essentially still done the old way.
There are still places in the code where the functionality of the
class could be used, most probably. ATM, it is used for InsetTabular,
InsetListings, InsetFloat, and InsetText.
The Comment and GreyedOut insets required a special treatment and a
new InsetLayout parameter (Display) has been introduced. The default
for Display is "true", meaning that the corresponding latex
environment is of "display" type, i.e., it stands on its own, whereas
"false" means that the contents appear inline with the text. The
latter is the case for both Comment and GreyedOut insets.
Mostly, the only visible effects on latex exports should be the
disappearing of some redundant % chars and the appearing/disappearing
of null {} latex groups after a comment or lyxgreyedout environments
(they are related to the presence or absence of a space immediately
after those environments), as well as the fact that math environments
are now started on their own lines.
As a last thing, only the latex code between \begin{document} and
\end{document} goes through the new class, the preamble being directly
output through odocstream, as usual.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37360 a592a061-630c-0410-9148-cb99ea01b6c8
that also makes sure it doesn't do more work than it needs to do, by
limiting the size to 40 characters. Previously, InsetBranch::addToToc()
would have added a string representing the entire contents of the
branch! It's hard to imagine that having to recalculate that sort of
thing doesn't cause some problems with speed, especially in documents
with lots of notes and branches and such.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36974 a592a061-630c-0410-9148-cb99ea01b6c8
