This fixes a crash in examples/fa/splash.lyx when selecting text
representing menu entries. This happens because menu names are in LTR
English, while the inset itself is in RTL.
The problem is that the current code relies on the fact that
1. getColumnNearX and checkInsetHit share the same idea about cursor
position.
2. pos and pos + 1 are in general consecutive on screen.
It seems that 1. is wrong here (for reasons I did not try to
understand); the second assumption is definitely false with
bi-directional text. This makes editXY very fragile.
The new code should be more robust in this respect. The logic is:
* if checkInsetHit finds an inset, use its position,
* otherwise, ask getColumnNearX for the cursor position.
Fixes: #9142
When deciding whether a paragraph should be indented or not, LyX
only takes into account default layouts. This is wrong, because
an environment could be nested into another one and thus a following
paragraph would not be "default". With this patch all paragraphs
after an environment are correctly indented, independently of
whether their layouts are "default" or not.
The latex output (which was modeled following the previous wrong
assumption) is also correspondingly adapted.
If a new paragraph is created just before a nested environment,
the indentation of the nested environment is not computed
correctly because the parindent of the previous layout would
also be erroneously taken into account. This would cause the
nested environment to move back and forth when something is
added to the new paragraph.
LyX fails to indent on screen a standard paragraph when it is
nested into an environment. The fix is a one-liner but the diff
is larger because it also fixes a previous wrong indentantion
in the source ;)
If a layout has NextNoIndent set to true, the following paragraph
is not indented on screen. LyX checks the previous layout for that
style parameter to decide whether to indent or not. Of course,
what matters is the latex output and the on-screen representation
should match this output. Now, when a layout has NextNoIndent==true,
the latex output is correctly not indented, while the on-screen
representation may fail to match this output. This can occur when,
for example, a standard paragraph is nested in the previous layout,
because LyX would check the property of the nested layout instead
of the container layout. Thus, LyX should check the property of a
previous layout at the same depth for correctly deciding whether
a paragraph has to be indented or not.
See also http://www.lyx.org/trac/ticket/9055#comment:12 for an
example document where the previous scenario actually occurs.
The algorithm used for breaking a paragraph in LaTeX export is changed
for avoiding spurious blank lines causing too much vertical space.
This change is tied to the introduction of a new inset (with two
different specializations) helping in either outputing LaTeX paragraph
breaks or separating environments in LyX. Both of the above goals were
previously achieved by the ---Separator--- layout and can now be
accomplished by the new inset in a more natural way. As an example,
after leaving an environment by hitting the Return key for two times,
a third return automatically inserts a parbreak inset, which is
equivalent to the old separator layout, i.e., it also introduces a
blank line in the output. If this blank line is not wanted, the
parbreak separator can be changed to a plain separator by a right
click of the mouse. Of course, an environment can still be separated
by the following one by using the Alt+P+Return shortcut (or the
corresponding menu key), but now the plain separator inset is used
instead of the old separator layout, such that no blank line occurs in
the LaTeX output.
Old documents are converted such that the LaTeX output remains unchanged.
As a result of this conversion, the old separator layout is replaced by
the new parbreak inset, which may also appear in places where the old
algorithm was introducing blank lines while the new one is not.
Note that not all blank lines were actually affecting the LaTeX output,
because a blank line is simply ignored by the TeX engine when it occurs
in the so called "vertical mode" (e.g., after an alignment environment).
The old ---Separator--- layout is now gone and old layout files using it
are also automatically converted.
Round trip conversions between old and new format should leave a document
unchanged. This means that the new behavior about paragraph breaking is
not "carried back" to the old format. Indeed, this would need introducing
special LaTeX commands in ERT that would accumulate in roundtrip
conversions, horribly cluttering the document. So, when converting a
modified document to old formats, the LaTeX output may slightly differ in
vertical spacing if the document is processed by an old version of LyX.
In other words, forward compatibility is guaranteed, but not backwards.
TextMetrics::getColumnNearX (x -> pos translation) has special code to
ignore spaces at the beginning of a row, but neither the display code
nor TextMetrics::cursorX (pos->x translation) follow this logic. One
might argue that spaces should actually be ignored (like LaTeX does),
but this leads to UI issues and is probably too difficult to
implement.
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?
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.
Only user of this function is code that has been commented out, comment
out this function as well.
Signed-off-by: Lars Gullik Bjønnes <larsbj@gullik.org>
As long as leftMargin() is not correctly implemented for
MARGIN_RIGHT_ADDRESS_BOX, we should also not do this here. Otherwise, long
rows will be painted off the screen and will not be editable.
If we are in rtl text, we *need* to check whether the first character is a
space. We can't use the rtl variable for this because this is only
computed on the last row.
This bug was introduced in [0a137e31/lyxgit] to fix the computation for
freespacing paragraphs. We better can just check whether the paragraph is
freespacing or not.
tells LyX not to show BLOCK text as justified, but still keeps
the usual paragraph indentation.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40427 a592a061-630c-0410-9148-cb99ea01b6c8
This was an attempt to fix#2743 without re-working the InsetBibitem
mess. It didn't work, so we have to do that.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38702 a592a061-630c-0410-9148-cb99ea01b6c8
This fixes the display of sweave Chunks in sweave.lyx example, which uses parskip instead of indent.
The rest of the changes are just white space
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37881 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
If there are use cases where this is useful, we can
think of a better way to reintroduce this.
Comments welcome.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35339 a592a061-630c-0410-9148-cb99ea01b6c8
DispatchResult to store a flag that tells us whether we need a buffer
update or not.
So: If you find a missing one, go to an appropriate place in the
dispatch and call cur.forceBufferUpdate() or, if you don't have a cursor
but do have a DispatchResult, call dr.forceBufferUpdate().
There is one remaining call I could not move, in
TextMetrics::redoParagraph. But this looks like an emergency call when
the macro context has not been set. There are also a couple calls that
are connected with buffer creation that I commented out, since the same
call is done again almost immediately. But I'm not positive about those.
Now the nice thing would be to do the same for updateMacros().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34826 a592a061-630c-0410-9148-cb99ea01b6c8
Investigation of this bug revealed that we are blinking the cursor even
when it is not visible. This should also be reverted. It may, in a way,
be that bug that caused this one, but this check is worth doing anyway.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33797 a592a061-630c-0410-9148-cb99ea01b6c8
It seems we realized the font in the wrong order. If the layout font specifies "Font Size Small", we should be able to make it large if we want to.
see:
http://thread.gmane.org/gmane.editors.lyx.devel/122682
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32129 a592a061-630c-0410-9148-cb99ea01b6c8
If the first character is a separator, we are in RTL text. This character will not be painted on screen and thus we should not count it and skip to the next.
This bug pretty much destroyed cursor placement in RTL text on a row with large gaps.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32116 a592a061-630c-0410-9148-cb99ea01b6c8
Math manual loads and save correctly it seems but expect some instability period.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31898 a592a061-630c-0410-9148-cb99ea01b6c8
If we correct the row where we put the cursor after a PgDn or PgUp command, then we should also adjust the y-coordinate that is used later for checkInsetHit and inset->editXY.
However, this code doesn't function like it should, but that is bug #4382.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31007 a592a061-630c-0410-9148-cb99ea01b6c8
TextMetrics::drawParagraph(): really check the whole row and not only the first word.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@30971 a592a061-630c-0410-9148-cb99ea01b6c8
Now inline SpellChecker is faster than ever. Now, I honestly think that we blow out all the competitors (thunderbird, OO, MSWord, etc) :-)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@30970 a592a061-630c-0410-9148-cb99ea01b6c8
In the computation of the row width, the last space on a row was included. However, this space is not drawn on screen and shouldn't contribute to the width. As a result all rows in a paragraph were painted slightly too far to the left, except the last on.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@30967 a592a061-630c-0410-9148-cb99ea01b6c8
The row in editXY is corrected when we're scrolling with PgUp and PgDwn to make sure that the row where the cursor is places, is completely in the view.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29752 a592a061-630c-0410-9148-cb99ea01b6c8
http://www.lyx.org/trac/ticket/4067
If we are in the first pos, we are never in the body and always in the label.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29033 a592a061-630c-0410-9148-cb99ea01b6c8
This is in preparation of some changes to be made in this function, now the change will only have to be done once...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@27656 a592a061-630c-0410-9148-cb99ea01b6c8
1. When a listing is inserted in a bit of text, the line above the listing is not drawn over the full width like it is done for lines above other insets. This is because InsetListing has a AlignLeft alignment. Now, if you start selecting downwards with the mouse in this empty area, strange selection drawings appear (see attachment).
This is caused by the fact that starting your selection at such a place, causes beg.boundary() to be true in TextMetrics::drawRowSelection(..). This is correct, but this value is true for _all_ selected lines. Now, the selection acts as if it is RTL text. Therefore, just like for end.boundary, this value needs to be reset for every line.
2. Starting your selection in an end margin often causes the selection in this end margin to be painted later. This is because when starting your selection in an end margin, you may have set a (possible empty) selection before really selecting the end margin. The problem is that the checksum (computed later) is the same for this empty selection and for the end margin selection. Therfore, we need a call to cur.setSelection() before evaluating cur.selection().
3. In the following two lines, it is assumed that there is only an end margin to be painted if the selection extends to the next paragraph. This is not true for the above described case of an AlignLeft Inset. Then, the margin has also be drawn within a paragraph
4. The end and begin margins are only painted when the selection extends into the following or previous paragraph. This difference is not resembled in the checksum if you first select a row completely and then procede to the next or previous paragraph as the selection remains at the end of a row. This also holds for the AlignLeft case. Therefore I added a term to the checksum to monitor whether the end and begin margins need to be drawn.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@26399 a592a061-630c-0410-9148-cb99ea01b6c8
* src/Inset.h:
- new member content Alignment that indicates whether the content
of text insets should be displayed with a specific alignment
* src/TextMetrics.cpp:
- handle inset's contentAlignment
* src/insets/InsetTabular.{cpp,h}:
- set contentAlignment for tabular cells.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@26380 a592a061-630c-0410-9148-cb99ea01b6c8
there is still one issue which is related (or so i think) to the pit is not being updated when extending a selection to a new row with cursor right/left. i left a FIXME in the code
i put this in since it is a uniform improvement on the current situation...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@24089 a592a061-630c-0410-9148-cb99ea01b6c8
