That way we do not match the whole table but only the cell contents.
The problem I had was
1.) Document language Spanish
2.) Table (copied from English doc) => language English
3.) All cell contents Spanish
Now search for English text led to a selection of the whole
table, although there was no English content in any cell.
With Qt 5.11 at least, RtL text will be drawn RtL even when the
(undocumented) flag Qt::TextForceLeftToRight is applied to the
QTextLayout object. This creates selection issues for Hebrew text
marked as English.
The solution is to do the same as in breakAt_helper, that is prepend
the string with a direction override unicode character.
Doing this requires to introduce a TEXTLAYOUT_OFFSET constant that has
to be used wisely to account for this extra character.
Fixes bug #11284.
The problem was, that the different list ennvironments
did not look different in tha latex output used for
search.
So the input of "\item ..." did not give information
if it is description, lyxlist, enumeration or labeling.
In search modus we use now "\item{enumeration}" etc.
Exception: findadv-21, but it is not a regression,
because this one never passed.
The problem here is, that we cannot differentiate
between enumeration, itemize, description and labeling
environment here.
Now tests findadv-01 ... findadv-20 pass too.
keytest.py: Expanded time for controll keys (like \[Return])
findadv*: expanded time for normal keys
lyxfind.cpp: Handle math equations
As it is now, searching with format needs ALL the features set
in order to match the pattern.
What needs to be done is a GUI specifying which of the features are
important.
1.) language
2.) font (series, shape)
3.) markup, underline, strikeout
4.) color
Having this info, the implementation is easy. Set
some variables and be done
We used to need a hack to set the size of the layout combo, but
the code was changed in Qt 4.5 or so. Hence the appearance of this
bug in 2009. We can now just remove this hack, and all seems to
work correctly.
The filters for the layout combo and document class combo share a
problem: If you type "beam", e.g, in the latter case, then we will
show any document class that contains those letters, in that order,
but not necessarily consecutively. This is extremely confusing and,
as José put it, just weird. So let's fix it.
I'd call this a bug so would be happy to see this in stable, too.
Further normalize the latex input in case of enabled format search.
It was not enough to split the latex input on \foreignlanguage and \textcolor
macros only.
Instead also macros like \textt, or \noun etc had to be accounted for.
This patch uses therefore a different algorithm.
In the latexified text:
* Check and handle contained regex properly
* Discard superfluos '{' preventing our search engine
to match with the search pattern
Our findadv expects something like
prefix + 'search'
so that the regex (which is latexified too)
can work on 'search'
(In the source, the prefix is denoted by lead_as_string)
The latex output contains structs like
\foreignlaguage(abc}{xx\textbf{boldxx\textcolor{blue}{blue 1 blue 2} XX}}
which would never match the simple prefix.
Now the above is converted to
\foreignlaguage(abc}{xx}\\
\foreignlaguage(abc}{\textbf{boldxx}}
\foreignlaguage(abc}{\textbf{\textcolor{blue}{blue 1 blue 2}}}\\
\foreignlaguage(abc}{\textbf{ XX}}
Of course, more than one language or color in an inset can be searched for now.
