We tend to have insets which buffer() member is invalid. To help
debugging, this commit paints their background in red when devel-mode
is on.
To this end, a new method develMode() is added to the Painter class.
With this commit, it is easy to see that macro template do not have a
proper buffer set!
Make InsetGrid::colAlign a normal method and make it check whether
buffer is valid before using it. This avoids crashes as we have seen
in 2.3.3 (see e.g. #11686).
There is still an assertion so that failure is noticeable before release.
This is done to ensure that numbering never overlaps equations. The
result can be different according to the bufferview, which is why
RowInfo::offset is now a std:map.
Remaing issues (how bad are theese ?):
- the numbering is considered too large when it overlaps the inset
rect, whereas one could consider the width if the current row
instead.
- previews may need to be adapted similarly to fit the whole screen width
This is the first (easiest) step in fixing bugs 10668 and 11333.
The numbering is now drawn outside of the insets, which solves the
alignment problems and make editing easier.
What does not work yet:
- long labels will overwrite equations. To fix this, we need to
implement the same algorithm as LaTeX and put labels on their own
row when required.
- previews may need to be adapted similarly to fit the whole screen width
Place autocorrect at the top of `InsetMathNest::interpretChar`,
ensuring that any autocorrections that trigger on special characters
(such as '^' or '~') work. In particular, you can now make an
autocorrection from "<~" to "\preceq"!
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.
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
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.
As evidenced in #11552, at loading time there is no way to tell
whether braces were added by LyX with certainty. However, after
[503f7db2/lyxgit], LyX does not automatically removes brace insets.
So, in case one faces the problems mentioned in [e8f480e7/lyxgit],
the workaround of adding a brace inset now will not be frustrated.
In essence, after [503f7db2/lyxgit], the real fix for #11552 would
have been reverting the part in [e8f480e7/lyxgit] that was adding
the braces on output.
