Since mc_search__run_regex() pften is called in various iterative
procedures, don't reallocate regex buffer every time and use already
allocated one before.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
In non-unicode locales, search for non-latin symbols in any acharset was
case sensitive only. This bug was introduced in
1a1496fc0d.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
The "Whole words" feature of search only worked in Normal mode, not in
any of the other modes (Regex, Hex, Wildcard).
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
...in case of "Regular expression" and "Whole words".
The bug:
If there's no match, it's properly reported so.
If there's a match, however, the mcview's viewport is properly scrolled
vertically, but the search result is not highlighted. Plus, you can
press "Search again" once (or more times if there are multiple matches
in the line) and it won't progress to the next match.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Using the "?" pattern in the file selection dialog brought up with '+',
mc uses the file name length in bytes instead of characters.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
Problem:
Suppose you want to replace a substring in some file names with another,
so you do a File Rename operation with source pattern:
*OLDSTRING*
and target pattern:
\1NEWSTRING\2
If OLDSTRING occurs inside a filename, it is replaced correctly, but if
at the beginning or end of the filename, the corresponding zero-length
wildcard match is replaced by literal \1 or \2, respectively.
Expected
Wildcards that match a zero-length substring should be substituted with
an empty string.
Thanks boris<> for the original patch.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
...for case where there is no MC_SEARCH_CB_INVALID or MC_SEARCH_CB_SKIP
return codes (for search from file manager), so we can copy line
at regex buffer all at once.
Thanks Sergey Naumov <sknaumov@gmail.com> for the original patch.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
When mc is compiled with SEARCH_TYPE_PCRE (and without SEARCH_TYPE_GLIB,
e.g. on systems with old glib < 2.14) case (in)sensitive search works in opposite.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
brace '}' (which probably isn't 100% correct), this should be checked in tests
for replace_handle_esc_seq function, not process_escape_sequence - it is the
replace_handle_esq_seq who decides whether it is an escape sequence or not.
Also, \x{4344} is usually a code for wide character (UTF-8), and not for "CD".
So we can either ignore the higher bits, or generate wide character codes...
The second would be convenient, but would also introduce a hard-coded UTF-8 charset.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Enables use of escape sequences inside regex replace strings,
Enables UTF-8 caseless search in PCRE.
Supported escape sequences: \DEC, \xHEX, \0OCT, \n, \t, \v,
\b, \r, \f, \a. Any of them could be enclosed into \{}.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
when searching in files for non english word with "Whole words" set "on" - then nothig will be found
try search word: "время" and also "time" in next example:
'time'
Время
'Time'
'время'
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
