The code that sets open_polyglossia_lang_ is not only executed for polyglossia,
but also for babel, so we have to use the correct language end command.
Since a while now we can translate the unit descriptions. For some special applications it is also necessary that the users know the LaTeX command of the relative units.
- also fix a typo in Customization.lyx
The context menu did no longer work for some insets, since it requires the
cursor to be in front, and editXY() is also used to determine the inset for
the context menu. Now the cursor is corrected if needed.
This was made visible by aab1b145a5, since xhtml export for
lib/doc/Additional.lyx caused an exception. However, the cause for this was
already present earlier: All attempts to output a std::string to an
odocstream resulted in trying to change the encoding of the stream instead,
since there is no operator<<(odocstream &, std::string) defined, and an
implicit conversion to SetEnc happened instead.
This is fixed by making the SetEnc constructor explicit and adjusting all
code parts that did not compile anymore after that. The parts of the code
that did use the wrong output operator were the std::string version of
htmlize() from output_xhtml.cpp and all changed parts in the other .cpp files.
I also removed the std::string versions of html::htmlize() and
html::cleanAttr(), since it was difficult to see which encodings were used
with these. Now we are always explcit when using html::cleanAttr() and
html::htmlize().
- there are some new packages required by LyX's supported document classes and example files
(this list is only used when LyX is installed the first time on a PC together with MiKTeX to shorten the installation time)
Previously, if one clicked onto a large non-editable inset like the new LyX
logo inset, the cursor was always positioned in front of the inset, even if
the click was almost at the back edge. Now the cursor is positioned at the
correct edge. I tested this also with RTL contents, where from means right
and back means left, but the inset anchor position anchor point is still
at the left, and the right edge is dim.wid pixels to the right of it.
The rule-of-three says that if any of virtual destructor, copy constructor
or assignment operator needs to be manually implemented, then all three
should be implemented. Otherwise you can get subtle bugs which can be
difficult to find. In the changed classes, changing a copy-construction to
an assignment would have had surprising effects. Now they all behave
consistently.
Found by cppcheck: (style) Same expression on both sides of '&&'.
I deduced the correct if-condition from the other places where theLaTeXFonts()
is called.
These were found by cppcheck:
Member variable 'x' is not initialized in the constructor.
The crash #9788 would not have happened if this had been done earlier.
The test case did show several problems:
- The alignment argument was not parsed correctly if it was not in braces
- There one column too much created, since I did not take into account that
the current cell must bge replaced by the multicolumn cell
- If the last line of an array contained only an empty multicolumn cell, then
the complete multicolumn was swallowed
- The decision whether to output the column separator & was sometimes wrong
for multicolumns
- also disable PDF-reply since this never works correctly and it could even destroy the whole PDF and exceeds the TeX capacity
- update the french version accordingly
This fixes the crash of bug #9788. However, the misparsing of \multicolumn
is still there: LyX thinks that the array has three columns, it inserts an
additional one before the multicolumn.
This was a regression from 2.1.x. I failed to copy the horrible hack that was present for the special case of () in Hebrew.
There is a real need for someone who understands RTL language stuff to fix this. Currently () are wrong in .lyx files IMO. We should not have to swap them for display.
This removes the old implementation of Cursor::getSurroundingPos, that has been superceded in commit .
As this was the last user of the Bidi class, this can be removed too.
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.
