The encoding used for your locale should be consistent with the one of the console (or tty, or virtual terminal).

So if "locale -k charmap" says:you should remove this line in /etc/lilo.conf:This will be the case for instance if LANG is set to en_US.UTF-8.

If instead you set LANG to en_US for instance you will get:Then you should keep "vt.default_utf8=0".

This has nothing to do with Midnight Commander per se, let alone with the time zone, only with usage of ANSI codes to display graphical characters.

The same apply to xwmconfig or any utility that relies on ncurses, for instance see http://www.linuxquestions.org/questi...ed-4175584782/

Taking the risk to look harsh, may I add that someone running -current is expected to be ready to deal with such changes as the ones quoted in the ChangeLog?

Of course you are not going to come across such issues under X, provided that you use suitable (and properly configured) terminal and fonts.

1 members found this post helpful.

As the instigator and lead developer of slint, I appreciate why you applaud the switch to UTF-8 as the default in Slackware. http://www.linuxquestions.org/questi...ml#post5574601
The need for internationalisation was brought home to me when I was seeding Slackware 14.2 as a torrent download, where I observed multiple accesses from every populated continent on the planet.
However, if this change to UTF-8 is as seamless as you suggest, then why did our BDFL choose not to throw the switch to UTF-8 until after the release of 14.2?
For the OP, I suspect the problem may have been the use of rxvt, which is part of official Slackware. But rxvt has problems when used with UTF-8.

There is the nub. Should Slackware-current continue to support programs that do not play well with UTF-8, but are perfectly serviceable if locale is changed back to the previous default?
The case in point here is rxvt. I have used rxvt for many years because it is lean by comparison to xterm. But now rxvt causes problems (e.g. mc, tree and man). The replacement, urxvt, fixes the problems but it is not a lean alternative to xterm and can also bring a host of issues if used with the perl options.

I assume because that means not only that the user will have either to abandon the few legacy utilities that are not yet able to handle UTF-8 encoding or use a (now non default) legacy encoding and associated font, but also take care of other aspects, like the many man pages that use various legacy encoding and that could need to be converted for consistency.

I rather assume that the OP is just using a Linux console with UTF-8 not enabled by default, which has been the recommended setting during installation until very recently.

This is a non issue: every one will be allowed to continue using a legacy encoding, both in the console and under X. That just won't be the default anymore.

PS Feel free to continue using a terminal of which the most recent release is dated 2003-03-26. After all it's only thirteen years old

Meanwhile I have enough resources to use xterm that has received continuous tender loving care from Thomas E. Dickey since 1996/1/6 (yes, that's twenty years ago), with the last patch dated 2016/06/25.

FYI xterm will be shipped in Slint 14.2 with a toolbar by default (I anticipate many rants from people not used to that but hey, any one can put a line with "XTerm.toolBar: off" in one's ~/Xresources then run "xrdb ~/.Xresources").

2 members found this post helpful.

I think that was indeed overly harsh. I didn't know what to do with that either.

What worries me is seeing posts like #6. The analysis is relevant:But not the conclusion:So as a reminder, -current:

• is not a "rolling release",
• is not a release at all.

Everyone is of course free to run it, but shouldn't expect the same stability as that of a release.

PS I did learn from this reading from Mr Dugan Chen, so I recommend it

2 members found this post helpful.