Re: [OT] ncursesw and UTF-8
On Sat, Nov 01, 2003 at 08:42:05PM -0500, David Yitzchak Cohen wrote:
> On Sat, Nov 01, 2003 at 06:42:57PM -0500, Thomas Dickey wrote:
>
> > probably. I see some occasional comments to the effect that there are
> > patches to make bash work properly with UTF-8, which implies that it
> > does not.
>
> bash most certainly does NOT work well with UTF. Here's my .inputrc,
> along with a comment at the end venting some of my frustration:
Actually it works fine. It just also has to be linked to support wide
chars. Just mutt has to be linked against ncursesw.
>
> $ cat ~/.inputrc
> set editing-mode vi
> #This is because editing-mode vi puts us in input mode by default:
> set keymap vi-command
> #This prints ls -F output in autocomplete candidates:
> set visible-stats on
>
> #Here's some stuff for internationalization:
> set meta-flag on #conservar bit 8 en entrada de teclado
> set output-meta on #conservar bit 8 en salida por terminal
> set convert-meta off #no convertir secuencias de escape
> #export LC_CTYPE=ISO_8859_1
> #For some reason, when I type international characters, they still appear like
> # weird backslashed numbers, but at least readline doesn't reject them, and
> they
> # look like what they're supposed to when they come out the other end ;-)
This is result of bad setup with locale. In my case I make sure that
there's absolutely no LC_ and no LANG variables in my enviroment. Then I
start xterm with the following command line
LC_CTYPE=en_GB.UTF-8 xterm -fn
'-misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-1'
In this case I don't even use special .inputrc and get all international
characters displayed correctly (if they are written as UTF-8 of course
:) And of course it's worth mentioning that en_GB.UTF-8 locale was not
available originally in my distribution so I had to create it using
localedef program. Note that since this locale is UTF-8 you don't really
care if it is en_GB or de_DE or whatever.
Andrei