This lfun (like several others) does not work with multicell
selection. Disable the lfun in this this case for now, until a nice
solution is found.
Fixes bug #12530.
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.
This happens when the cursor goes into a deeper inset, since
selectWord() was called on the wrong Text object.
Additionally, fix the new word selection when cursor goes before
existing selection.
Fixes bug #12529.
With an updated TeX Live 2022, LuaTeX no longer gives a missing
symbol for this test file (manual inspection confirms the symbols
are correctly displayed).
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.
This fixes two issues with autoconf 2.71
* a new version of eilseq.m4 from libiconv is required ;
* the AC_CHECK_HEADER last `-' argument is obsloleted, but I do not
think that we needed it in the first place.
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.
1/ put cusror in some display inset
2/ use shift-left until the cursor exits the inset
3/ see how the selection extends on the right.
This is not really a selection drawing bug, but rather the fact that
the anchor will be normalized to the first position after the inset,
which is in the next row.
This can be avoided by using the boundary property.
See discussion in bug #12520.
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.
