Using unordered_map instead of map.
Reasons:
1.) The relevant maps contain 166(Keys) and 649(Accents) entries.
This mean that average access with 'map' needs 8 to 10 compares to find the value.
2.) Since we are using at least c++11, the unordered_map is available
2.) increasing the maps (in future) needs not to be considered anymore, because
the access-time will not increase.
In case of search with format:
If the pattern contains language spec different to the document language
then do not ignore language setting.
Also renamed 'matchstart' in FindAndReplaceOptions to 'matchAtStart'
Since commit c600906d92 all matches are match-results of examined strings starting
with a character of the same cursor depth, we can be sure to match the same string again if:
1.) the number of characters to the end of the examined strings match.
2.) the match-lengths are identical
1) Take care of different input if changed the search-mode (with/without format)
This amends ec387b6d
2) Make the braces used in text to be treated as single characters
e.g. transform '\braceleft' to some unicode value
3) Try to use '$' as 'end of sequence' in regex
We have to remove '}' and '\n' chars from the examined string
In format-search the chars '{' and '}' are understood as latex parentheses, which normally are not
part of text and are discarded.
Instead we fake them as if they were a char like \backslash or \guilemotright or such.
Makes the code with less exceptions
(no need to differentiate beteen use_regex and !use_regex)
Move the creation of regexes to own subroutine (Handles '#if QTSEARCH ... #endif')
Use cursor position differences instead of length of matched string. This is important for putSelectionAt()
Otherwise we are unable to distinguish text from latex commands.
For instance '\color{blue}' in text-part is normal text, while othervise
it defines following characters as being blue colored)
Use innermost nesting to start searches.
Some fine tuning to determine correct match.
(If the regex contains '(\S)\1' at the end, then this regex would match '}}',
but this is often the case at and of examined string. We have to disable this invalid match.
)
This regex handling is part of QT5. For lyx which uses QT4
findafv will still work, but is not good for caseinsensitive matchings
in handling non ASCII characters
I misinterpreted the unicode creation 'u8"\uF00xx"'.
The C++-compiler saw 'u8"\uF00x" "x"', but this was not intended.
The routine which mimicked is doing the right job now.
For search we used to lowercase for everything, but sonce the regex itself
should be left unchanged, this change was needed.
Works nice with ASCII, but fails miserably on on other UTF8 points (like Cyrillic chars)
