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. :-)
In python it is possible to compare tuples with a lexicographic order.
Take advantage of that since there is no need to resort to the C-trick of converting a version in hex format.
We need to set a dummy version in case we are using ImageMagick to ensure that version is always an integer 3-tuple.
It worked in python2 but not the way the authors imagined. Because hex always returns a string.
From python2:
>>> 1 > "2"
False
>>> "2" > 1
True
>>> "1" > 2
True
The rational is that an integer is always smaller than a string.
In python 3 this because it does not make sense to compare objects of different types.
Amends 7bb30286.
Tested cases are now handled fine.
(There are still many cases where the language support emulation
is too complex for lyx2lyx and manual fixes are required after
lyx2lyx conversion.)
The first step is to move the MathRow cache to BufferView, alongside
coordCache. This was on the todo list anyway, since it allows to let
go the math row information when the math equation is not on the
screen anymore. With the old scheme, it would always remain in memory.
Then, when computing caret size in MathData::metrics, make sure that
the mathrow of the elements that are linearized in the MathRow object
get their caret size information initialized too.
Fixes bug #11587.
Correct or activate some already present shortcuts, and add new ones
for easily obtaining the most common fixed size delimiters.
Pressing '*' after a delimiter will cycle through all sizes.
