With non-TeX fonts, the \inputencoding setting is overridden
by "utf8-plain" (pass-through). Keeping the old value allows
switching back to TeX fonts without the need to (re)set
the input encoding.
Also change back the GUI name of the "auto-legacy" setting
(cf. #11115).
The culprit here is the constructor QString(QByteArray const &): in
Qt4, it would interpret the byte array as latin1, and in Qt5 as utf8.
Therefore it is safer to use explicitly QString::fromUtf8 instead of
this constructor.
Several places where additionally simplified, in order to avoid some
extra conversions.
Ensure the default encoding "utf8" comes always first,
followed by other common variants.
The encodings were sorted based on the GUI name which leads to
the default setting moving from the top position in some localizations.
Recent gcc versions return a short version with -dumpversion, e.g. 9.
In this case, use -dumpfullversion, which gives something like 9.1.0.
This makes the gcc 9 detection work properly.
The warning about unneeded std::move can be solved by conditioning on
C++14 mode.
The warnings about deprecated copy is harder, so we disable it for
now. We will be able to fix our part, but Qt triggers it a lot too.
At the time, there were two competing packages for French language:
frenchle (aka french.sty), the historical one, and frenchb.ldf, the
new kid on the block. I was difficult to know which one was loaded by
babel, and frenchle did not define \og and \fg. Thus the need for our
own definition.
These were the good old days, but this time is gone for good.
Without this some encoding-names would not be translated.
The extra used chars are '[', ']' and '/'
like in lib/encodings:55
Encoding utf8x utf8x "utf8 (extended) [ucs] (utf8x)" UTF-8 variable inputenc
python23_call: determines if the binary given is appropriate and adds the necessary calling options
find_python_binary: get a list of candidates and choose the right one using python23_call
python: returns the name of the python interpreter that can be found on PATH, using find_python_binary
Now we report these in the same way as LaTeX errors (but let the user to
see the result anyway). It remains to be shown much is this disturbing
to users. Generally, ignoring these is not a good idea, because they are
harder to manually spot in longer documents.
The details of reported error varies because log linebreaks at 90
induced by pdflatex make log harder to parse.
The committed code is more robust than previous, in which some missing
cits/refs with long keys would go unnoticed.
Tested on bibtex and natbib.
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg208912.html
It is now possible to specify in the lib/language file whether screen
rows can be broken anywhere (CJK languages) or only at work boundary.
Set WordWrap to false for the CJK languages (notice that japanese-cjk
had been forgotten before).
Moreover, remove a test for separators in row element that was not
really helpful.
Fixes part of ticket #10299.
FWIW this code is important for very old versions of lyx, older than 1.1.5 (released 19 years ago - 2000/06/06).
Funny fact of the day, byte strings do not behave as regular strings in python3 when taking and index.
To get a sub-string we need to pass a range, a integer index will not work as it happens in a regular string:
$ ipython3
...
In [30]: line
Out[30]: b'#This file was created by <mike> Tue Jan 25 10:36:51 2000'
In [31]: line[0]
Out[31]: 35
In [32]: line[0:1]
Out[32]: b'#'
The range notations works for both byte and regular strings in python 3, and it also works in python 2.
Thus the change is simple and effective. In any case I should confess that I was quite surprised by this. :-)
