* 3235_copy_with_special_symbols:
Add '?' sign as a possible mark of wildcard.
Fix for issue:
Ticket #3235: copy files dosn't work as expected, when copying to a directory with the special symbol in its name
When copying to directory with a name containing special symbol "*" the copy command didn't do it in a right way.
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
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>
* 2309_shell_patterns:
The patch does not intend to fix all Bash patterns (I believe mc never claimed to support all kinds of them), but it fixes some issues. 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.
Ticket #2309: "Shell patterns" broken beyond repair.
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>
How to reproduce:
Either on the command line, or in any other text entry field (e.g. copy
file to) enter a string where the last word consists of one single
letter only. E.g. "abc de f".
Press Alt+Backspace.
Expected behavior: Remove the last word, that is, the letter "f" only,
leaving "abc de ".
Actual behavior: Yet another word is removed, leaving "abc ".
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
At certain terminal widths (including the default 80), if the last byte
of a line begins a CJK character then the corresponding glyps is drawn
in the last column, so it's replaced by a replacement symbol.
The default layout should, at all possible terminal widths, have an
extra last character column that is empty normally, but allows room for
a CJK to overflow here.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
(mcview_handle_editkey): an is_printable() check was performed for every
byte of the UTF-8 which obviously doesn't make sense. This check
shouldn't be performed for 8-bit charsets either. If the given byte can
arrive as input, the file should be modified accordingly.
The TAB key shouldn't be accepted as literal, to allow moving back to
the hexview area.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
UTF-8 characters show up nicely in the right column (followed by a space
to align with the number of bytes).
However, as soon as you edit the file (either by the hex codes, or by
moving to the right column and entering an UTF-8 character), that
character doesn't show up there.
Expected: during editing the file, the right hand side should
continuously be updated to look exactly as if that was the original
contents of the file.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
