-
-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
can't rename file in non-English #997
Comments
OS? Original name is in Cyrillic and looks correct? What's the output of |
Original file can be in Latin/Cyr, the same weird characters appear after typing in Cyr.
|
I also assume that you're starting |
Correct.
Same issue. Also tested on Xterm and Ubuntu 24.04 LTS. |
I'm running out of things that could affect the outcome. There is a conversion from wide to narrow encoding because input is processed as Unicode, but is then converted to local encoding, which is why locale could make a difference. One thing you could try is renaming a file in Vifm to I'll also need to check in a VM if I get the same on 24.04 LTS. What's the other distribution where you see the issue? |
Thanks, that is not what I expected. |
So far I wasn't able to reproduce this inside docker or a VM with Ubuntu 24.04 LTS. |
OK, tested on Linux Mint and it works. Does Vifm needs any extra build dependency for non-EN lang support? |
No, if locales work, the rest should work. I just tried |
wget_wch() from ncurses doesn't return non-latin input on Clear Linux. The input result looks like Ctrl+Space combination which internally represented as Test program
// 1. Save as test.c
// 2. Compile:
// gcc -Wall -g -o test test. -lcursesw
// 3. Run:
// ./test
// 4. Type in something
// 5. Quit by pressing Escape key or Ctrl+C
#define _XOPEN_SOURCE_EXTENDED
#include <curses.h>
#include <locale.h>
#include <stdlib.h>
#include <wchar.h>
#include <wctype.h>
static WINDOW *win;
static void init(void)
{
printf("MB_CUR_MAX: %ld\n", MB_CUR_MAX);
setlocale(LC_ALL, "");
printf("MB_CUR_MAX: %ld\n", MB_CUR_MAX);
initscr();
win = subwin(stdscr, 1, getmaxx(stdscr), 0, 0);
refresh();
}
static void setup(void)
{
noecho();
wtimeout(win, 1000);
}
static void loop(void)
{
wint_t c = 1;
int result;
result = wget_wch(win, &c);
while (c != 27) {
if (result == OK) {
if (iswprint(c)) {
wchar_t buf[] = { c, 0 };
waddwstr(win, buf);
} else {
wprintw(win, "[0x%04x]", c);
}
wrefresh(win);
}
c = 1;
result = wget_wch(win, &c);
}
}
static void clean(void)
{
delwin(win);
endwin();
}
int main(void)
{
init();
setup();
loop();
clean();
return 0;
} It exposes the same behaviour as Vifm which makes ncurses build on Clear Linux a likely cause of the issue. An alternative is that the program has the same issue as Vifm which I just don't see. However if I build ncurses 6.4 manually like here vifm/pkgs/AppImage/genappimage.sh Lines 40 to 49 in fc7c369
and link that test program or Vifm to it, I see no issues, so it seems to be related to packaging of ncurses. It's possible there is something that Vifm could do in this regard, but at the moment I don't think what that could be.
|
Wow, thanks for digging. Seems like it's related to strictly non-English characters: tested |
iswprint(key) won't handle it properly because Ctrl+Space is '\0' and it's translated to a custom WC_C_SPACE to be able to process it given that it normally signifies ends of a string. See vifm#997 (comment)
Tested using
cw
andcW
, got something weird:123
Version: 0.13
The text was updated successfully, but these errors were encountered: