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
Patch slang-refresh.patch by Egmont Koblinger (firstname.lastname@example.org) implemented.