The unicode representation in an ascii-string string is
\302\240 Normal space
\342\200\257 Non-breaking Thin (1/6 em)
\342\200\213\342\200\205\342\200\213 Medium(2/9 em)
\342\200\213\342\200\204\342\200\213 Thick (5/18 em)
\342\201\240\342\200\202\342\201\240 Half Quad(0.5 em)
\342\200\203 Quad(1 em)
\342\200\203\342\200\203 Double Quad(2 em)
\342\220\243 Visible space
'Double Quad' counts as 2 spaces, all others count as 1 space in the search regex
Qt4 code has been identidifed by
git grep -l 'QT_VERSION.*\(0x050000\|0x04\)' src
Uses of QT_VERSION_CHECK have been checked too.
been used to remember what places need further work.
Then remaining Qt4 references have been searched using
git grep -i qt4
git grep -i 'qt 4'
and relevant issues have been either fixed or noted in the new
TODO.killqt4 file.
In several range-based for loops, implicit copies are made. Remove
that when possible, and try to shut converity up otherwise.
Fixes issues found by coverity.
In FindAdv we use Qt to interpret regular expressions.
Regex uses for instance '\w', '\d' etc.
'\d' finds not just '0-9' but also e.g. '߂' (Nko Digit Two: U+07c2)
'\w' includes also such numbers.
ATM, only FindAdv uses this function.
In this case we skip the undesired word-characters before starting the search.
There are still some inconsistencies between LyX and Qt of 'what counts as a word-character',
but too hard to resolve.
Since the element 'match_len' in class MatchResult is an integer,
the check 'if (!match(...).match_len))' is changed to
'if (match(...).match_len) <= 0)'
1.) The type of variable at_begin changes from bool to enum matchType
true -> MatchStringAdv::MatchFromStart,
false -> MatchStringAdv::MatchAnyPlace
2.) discard default parameter-values of
MatchStringAdv::operator()
MatchStringAdv::findAux()
1.) Changed arrays dept and closes to vector-type because of runtime error in UserGuide.lyx
with a big paragraph (size > 8900 chars) contained too many opening parentheses
2.) Removed one creation 'textcyrillic'-key because it is later anyway created
3.) Most important (thanks to Scott who found the failure)
Move the check if the found string really is part of MATH to
the relevant place.
Without this change the search using 'Search only in maths' will fail miserably.
To handle this case, we use '\lyxdollar' string instead.
Also try to handle '\n' in the docstring directly instead in the
string already converted to utf8.
(The utf8-version is still there, but commented out)
If the searched area contains deleted parts, there may be more closing
as opening parentheses in latex output. We have to remove them before
further processing.
Using the new inline statements
find_effective(), find_with_non_output(), find_with_deleted(),
find_set_feature(), find_add_feature() and find_clean_features()
makes the code a slightly better readable.
Also fix a thinko in interpreting the found values.
The match_len describes the length of the second regex field,
while matchend is the length of the search field 0.
We are removing leading values from the start of string, so
the size of removed data was wrong because s.find() could find
a position inside the leading part.
Problem occured if
1.) not using regex and
2.) search without format and
3.) the search pattern ended with '}'.
then this last char '}' in the search pattern was discarded.
With the debug-level 'find' there are now less output.
The original output can be received now with debig-level 'findverbose'
Also constructions like
LYXERR(Debug::FIND|Debug::FINDVERBOSE, "...");
are now possible.
Difficult to decide, when to remove the sequence '%\n'.
The sequence is OK for latex output as a command separator,
but must be removed in searched string.
Alas, not all occurences are wrong. Sigh.
