The old instructions did assume that the MSVC bin directory was in the PATH.
This is not recommended, since it gets in the way if you want to compile for
32 and 64 bit. Therefore it is now described how to configure without the
PATH dependency.
We recommend MSVC 2015 now, because of better C++11 support and MSVC 2010 is
not available anymore. Also update several pathsdue tro changed dependency
packages.
Previously the commandline arguments were processed in an operating system
dependent encoding if running under python 2. Now they are converted to
unicode during the parsing, using the more modern argpase instead of optparse.
The individual conversion methods do no longer need to know anything about
commandline encoding. This fixes a bug similar to #10218 if running under
python 2 which I probably introduced during the python 3 conversion.
This was dead code that did never work, and most of it was boilerplate that
you can steel in 15 minutes from any existing math inset. Apart from that it
did contain a pointer to InsetXYMatrix which would create the same problems
we saw with the macros.
icu.{hpp,cpp} is not needed and cannot be compiled since it depends on libicu.
The other two files are currently not used, but could be in principle, so I
added them to the build.
The version is read by checking the macros __clang_major__,
__clang_minor__ and __clang_patchlevel__. Hopefully they will have
coherent values everywhere.
For now, the version is used to set warnings a bit more reasonably for
older clang versions, which do not support -Wdeprecated-register and
some others that are used in pragmas in boost.
This removes many warnings when compiling with clang 3.3.
This requires to change many docstrings into std::strings. The logic behind that
is that they represent a fixed set of math fonts, and therefore “string” means
here “poor man's enum” rather than text (this is consistent with MetricsBase).
Profiling of scrolling inside a document over macro-instensive areas:
Before the patch:
44,1% BufferView::updateMetrics()
-> 34,8% InsetMathHull::metrics()
-> 9,8% FontSetChanger::FontSetChanger()
28,4% BufferView::draw()
After the patch:
35,3% BufferView::updateMetrics()
-> 27,2% InsetMathHull::metrics
-> 0,4% FontSetChanger::FontSetChanger()
47,5% BufferView::draw()
FontSetChanger::FontSetChanger() is made 41x less expensive (with reference
BV::draw()) just by removing this conversion. The remaining 0,4% could be
squished by replacing the strings with a proper enum, but this is premature. Of
course, this only treats the symptoms: there is no good reason that this
function is called 45500 times over the time of 40 repaints.
Replace the manual manipulation of a stack of RowEntries with a Changer
function. When I introduced the stack of RowEntries, I did not know about the
Changer mechanism.
* Inset::canTrackChange() had two meanings: can it deal with change tracking?
Will it paint its own CT status? The latter information is now given by
Inset::canPaintChange().
* Line thickness computation is moved from RowPainter to MetricsBase.
* Painting function for Changes moved to lyx::Change. (One new, that strikes
diagonally.)
RefChanger temporarily assigns a value to a non-const reference of any
kind. RefChanger provides a flexible and uniform generalisation of the various
scope guards previously derived from the old Changer class in MetricsInfo.h.
As before, a temporary assignment lasts as long as the Changer object lives. But
the new Changer is movable. In particular, contorsions are no longer needed to
change a private field. Special code can be moved into the appropriate classes,
and it is no longer necessary to create a new class for each specific use.
Syntax change:
FontSetChanger dummy(mi.base, value);
-> Changer dummy = mi.base.changeFontSet(value);
New function for generating arbitrary Changers:
Changer dummy = make_change(ref, val, condition);
Bugfix:
* Fix the display of \displaystyle{\substack{\frac{xyz}{}}} (missing style
change).
The LyX class works now with python 3. Certain file format conversions may
still fail (convert_multiencoding() is a hot candidate), but this will need
to be fixed in the individual modules.
