Wrong behaviour before this commit:
Open new lyx-file
insert
unicode-insert 0x025c 0x1d08
Open adv-find dialog
search for unicode 0x025c OK
search for unicode 0x1d08 OK
search with regex for unicode 0x025c OK
search with regex for unicode 0x1d08 ==> NOT OK (because we are searching for \textrevepsilon
and this was mapped to 0x025c
Fixes bug reported here:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg217265.html
1. Start a new document.
2. Start a math inset and inside put "1+2".
3. Put the cursor to the right of "+".
4. Press <Shift> + L three times. This will select the entire math inset
(as expected).
5. Press <Shift> + R.
Before 503c7c16, the selection inside the math inset was preserved.
After 503c7c16, it is lost.
The problem is that InsetMathNest does too much for our needs and
resets the anchor (why, I do not know). Therefore, it is better to
duplicate the code.
These are just annoying. Note that the language mark cannot currently
be specified in a layout file, but it is not clear that there is a
need for that. Therefore I used the simple and hackish way.
This is actually a generic InsetInfo issue:
1/ the contents of the inset is computed in updateBuffer, so that it
is available for drawing but also for latex output (think batch
export). When it is called, it deletes the existing inner paragraph
and replaces it by a new one
2/ metrics build a new Row object that represents to paragraph
3/ draw() relies on this information
Now, imagine that updateBuffer() is called after metrics(). This can
happen for many reasons, and does happen here (display a shortcut info
and change the shortcut file from cua to emacs).
This problem has been here forever, but is only visible now that the
(experimental) bookmark display code needs to read the underlying
paragraph id.
The solution is to compute the inset contents at metrics time. This
is done by moving the relevant code to a new standalone build() method
that is called in metrics() but also in latex().
Both lyx2lyx and LyX write output to the terminal, and it's helpful
to know which messages are coming from lyx2lyx. For example, before
this commit if we opened a document in LyX that has a newer file format than
lyx2lyx can deal with, we see the following output in the terminal:
Warning: 619: Format not supported.
Warning: Quitting.
Error: Document format failure
The first two lines (the warnings) are output from lyx2lyx, and the
third is output by LyX. This output was particularly confusing
because I first thought "LyX tries to quit if the document is too
new?", but in fact LyX still stays open; it just doesn't open the
document. After this change, the output is now the following:
lyx2lyx warning: 619: Format not supported.
lyx2lyx warning: Quitting.
Error: Document format failure
These exports now pass, and a quick check of the output looks good.
These might have been fixed (although it is just a guess) due to the
following entry in the changelog of luaotfload v3.19:
A new algorithm for selecting fonts based on font family names
allows to more reliably load fonts based on their family name.
This commit reverts 2a665dcc.
