Hide Forgot
I don't know if you still care about the 8-bit (non-UTF8) behavior of applications, I hope you do. UTF-8 patches of slang+mc introduce a bug which is not present in mainstream slang+mc, neither in the patched version in UTF-8 environment. However, it's an annoying bug if one runs the patched slang+mc combo inside an 8-bit terminal (e.g. LC_ALL=hu_HU vte). Create a simple short text file with several lines, where some of these lines start with a lowercase x letter. Press F3 on this file to view it with mc's default viewer. Wherever the vertical line in the leftmost column of the display should contain an 'x', the vertical line remains there. (Most likely because it's ACS code or whatever is 'x'). ^L repairs the screen but then when you leave the viewer, you'll see x characters in the left edge of the panel. utf8-patched slang plus mainstream mc causes the same problem, so the bug must be inside the utf8-patched slang.
Created attachment 107086 [details] solves the problem for me This patch solves the problem for me and survived a quick one-minute testing in both latin2 and utf8 mode mc. The problem is that in latin2 mode the code of 'x' and ACS_VLINE only differs in the highmost (0x80000000) bit which is masked out by the CHAR_EQS macros (when sldisply.c's SLtt_smart_puts() calls CHAR_EQS(*q, *p) ), which hence thinks these two characters are the same. The second part of my patch actually reverts one hunk from the debian patch. I'll keep on using slang with this patch and I'll let you know if I found something misbehavior.
Patch slang-refresh.patch by Egmont Koblinger (egmont@uhulinux.hu) implemented.