Inside a math inset when completing macro names, it could lead to crashes.
Note that this processUpdateFlags is present when outside of this if() branch.
When inserting inset over a selection, the layout is transferred if
the inset covers full paragraphs.
This is not the right policy in the case of environments. Until proper
code is written and tested, limit ourselves to command layouts.
Fixes bug #12251.
Typical example is a Labeling layout which label is an inline equation
larger than the screen. Before this commit, the row would not get
broken at all.
Two parts in the patch:
1/ when breaking the row in shortenIfNeeded, mark the last element as
AlwaysBreakAfter instead of BreakAfter, in case the next element is
NoBreakBefore.
2/ when nothing could be done, as last resort keep the first element
of the row only.
Prevent the return of impossible values for 'enum flags'.
For instance the result of '~Update::Force' at src/BufferView.cpp:3025 without this patch
is '4294967293'.
The string that Qt sees is not the original string, since we add
zero-width nonbreaking spaces around it, plus an override character to
force rendering direction. This means that translating positions
between these two representation can be a bit tricky.
We use a max(foo, 0) here to make sure that our intermediate
computation is postive.
Fixes part of bug #12452.
Setting sufficiently high value allows to use
ColorCode enums for new up to 32000 branch insets.
Previous setting printed messages if using more than 25 new branch insets.
"'ColorCode' ... src/Color.cpp:435:10: runtime error:
load of value 128, which is not a valid value for type"
It is not a good idea to take into account the horizontal scrolling
that may have happened. For example, this leads to display glitches
when a Description label is larger than text width.
This explains why SingleParUpdate strategy did not work with home/end
on a long row.
The spacing of Labeling, Description and friends shall be computed
when breaking the row, not when tokenizing it. Indeed, this is the
right place to determine its correct value.
To this end add a new MARGINSPACE row element type.
This allows to remove TextMetrics::labelEnd, which is not used anymore.
When a string is broken at the margin by the Qt algorithm, the space
at which breaking occurred is automatically skipped in width
computation. However, the ending space of the string is taken into
account and is visible for example at paragraph end.
When the trailing space is followed by a displayed inset, then the
space should be skipped too, which means that the width of the last
row element has to be recomputed. For the sake of performance, the
width of the element without trailing spaces is computed in advance in
FontMetrics::breakString.
This "no space" width will be used when trimming a row element of its trailing
spaces instead of the original one.
Additionally, do not trim trailing spaces when the row is flushed.
Fixes bug #12449.
The search widget triggers a showEvent() in updateTitle() leading to setting the focus to the default push button.
The check in updateTitle() for the need to restore the title avoids superfluous show events and avoids the unwanted focus change.
This ensures that we use a consistent Python interpreter in LyX.
$${python} is replaced by the Python version found.
Users can apply this in preferences and use the same version defined by
LyX.
An inset that resets its font (like Footnote) does not care at all
about enclosing font. Therefore the real starting point is the class
default font. This avoid cases where the footnote contents is forced
to \normalsize.
It turns out that the Greyedout note inset, did inherit font but was
declared as not doing it. This commmit changes the definition by
adding \normalfont\normalsize so that no inheritance happens.
Note that actually \normalfont resets everything but the font size.
This does not matter for footnote (which has its own font size) and
greyedout (which is fixed now), but may matter elsewhere. Also, I do
not know what the situation with HTML is.
We could not figure out the root issue, or at least not to the point
where we felt changing this code considering we could not trigger
any bug from a user perspective.
For now, we just add a comment in the code.
For more information, see our ML discussion here:
https://www.mail-archive.com/search?l=mid&q=20211227113249.53bf5a63%40admin1-desktop
Use cases from #12352. The files correspond to
mwe-remove-bottom.23.lyx and mwe-remove-top.23.lyx. The only
differences are that I changed to FreeSans and FreeSerif for the
fonts.
