Currently, math autocorrect allows to transform a couple of characters
to a new one. This patch allows to transform a couple (sequence,
character) to a new character.
No example are implemented right now. One possible idea would be
"--" + ">" => \longrightarrow
This is related to the bug #11457 saga and it was my fault.
The debug files should be written only be on if the argument --debug is passed and not --verbose as it was done by mistake.
This effectively allow paragraph breaks in insets only for cosmetic
reasons (e.g., to align contents on different lines).
This is the last change necessary for an enhanced covington gloss support
(which uses the new covington gloss ui)
In python 3 the colors need to be strings and not bytes:
This was the equivalent of
>> print("%s" % b"1")
"b'1'"
since the colors were bytes the call to dvipng was something like
dvipng -Ttight -depth -height -D 115 -fg "b'rgb 0.937255 0.941176 0.945098'" -bg "b'rgb 0.137255 0.149020 0.160784'" "lyxpreviewxBJEqm.dvi"
Note the "b'rgb after both -fg and -bg that wrecked havoc and thus dvipng failed. That was the difference between python2 and python3 calls.
See https://marc.info/?l=lyx-devel&m=155879185229073&w=2.
The problem is that, after saving the document and reloading, the
TOC is corrupted, more or less, when we run through updateBuffer.
So we reset it first.
The mhchem \ce inset is a text mode environment but allows entering
spaces and mathmode commands. However, even if it doesn't allow unicode
symbols, LyX allows entering them (by copy/paste, for example), causing
latex errors. As a unicode symbol may have a proper latex representation
from the unicodesymbols file, use it instead of the bare symbol. Here, we
don't care about the mode because both text and math mode should be allowed.
For example, the ⟶ symbol is not recognized but its latex representation
(\longrightarrow) is fine. Of course, there may be symbols that are
not recognized anyway, but this is better because they cause explicit
errors from mhchem instead of cryptic iconv errors in case they cannot
be represented in the document encoding.
Prepare for languages that use CJK with TeX fonts and Polyglossia
with non-TeX fonts.
Korean is already supported by Polyglossia,
LyX support will follow (file version change).
