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>
Namely, backslash-escaped metacharacter like {}*? will remain in the pattern (with the current code it is just stripped). Second, comma will be transformed to | only inside a group.
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>
...if file encoding and locale are different.
Example: locale is KOI8-R, file encoding is UTF-8. Note: those encodings
are not same.
File content is following (in Russian):
йцукен
Йцукен
The difference is in first line char only: Й (lowercase letter) and й
(uppercase letter). The search of Ê gives the result Й independently of
case sensitivity. й isn't found.
If switch "All charsets" on, nothing is found.
The main idea of fix is modification of search API to allow set of search
pattern charset and use if within search engine.
Old API:
mc_search_new (pattern, pattern_len);
New API:
mc_search_new (pattern, pattern_len, pattern_charset);
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Test case:
1. Create a file with name that contains some special chars:
touch attachment.cgi?id=564208
2. Press F6.
3. Press a. Now only the 'a' letter is in input line.
4. Press Esc Tab Enter.
5a. Input line is filled by 'attachment.cgi?id=564208'...
5b. but 'attachment.cgi\?id=564208' is expected.
6. Add 'patch_' before file name:
'patch_attachment.cgi?id=564208'.
7. Press Enter.
8a. Result: 'patch_attachment.cgiattachment.cgi?id=564208id=564208'.
8b. Expected result: 'patch_attachment.cgi?id=564208'.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
(mc_search): immediately return FALSE if str is NULL.
(mc_search_run): immediately return FALSE if user_data is NULL.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
Set defines via CPPFLAGS variable not via CFLAGS one.
Use AM_CPPFLAGS and AM_CFLAGS variables instead of per-target ones.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
In Search dialog in mcedit M-n hotkey was used for normal search mode.
Therefore, M-n as HistoryPrev in the input line was in accessible.
Change hotkey for normal seach mode to M-r. Use this hotkey for normal diff
mode in mcdiffviewer to unify i18n resources.
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>
Hexadecimal values like "2d f0" can be used as well as "0x2d 0xf0"
in all search dialogs where hexadecimal search is supported.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
(mc_search__hex_translate_to_regex): don't use length of original string
after leading whitespace trim.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
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>
