[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#139771: Bug #163031 and #139771 - Request for UTF8 mode

unmerge 163031
tags 163031 -upstream
unmerge 139771
tags 139771 -upstream
reassign 139771 zsh
merge 139771 205651

Both reports are wrongly assigned. They were assigned to the
kernel but the kernel does not manage X pseudo terminals
input/output, only the vga and framebuffer console are its

Also x terminals does not manage utf-8 i/o by themselves, the
shell/interpreters (zsh , python) does.

zsh is still buggy so i reassign #139771 to  zsh and merge it
with the already available bug reports of zsh with utf8 (#205651)
(even zsh beta does not handle utf-8 characters).
But the python issue is fixed (python 2.1, 2.2 and 2.3). I will
only reassign this issue to zsh.

I will close :
for lack of submitter responses and no usable information even
for a reassignment.

I also remove the upstream tag from it as linux and xterm already
support utf-8 upstream and in debian.
> http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod
I guess it was about:
> The tty driver of any POSIX system supports a "cooked" mode, in
> which some primitive line editing functionality is available. In
> order to allow the character-erase function (which is activated
> when you press backspace) to work properly with UTF-8, someone
> needs to tell it not count continuation bytes in the range
> 0x80-0xBF as characters, but to delete them as part of a UTF-8
> multi-byte sequence. Since the kernel is ignorant of the libc
> locale mechanics, another mechanism is needed to tell the tty
> driver about UTF-8 being used. Linux kernel versions 2.6 or newer
> support a bit IUTF8 in the c_iflag member variable of struct
> termios. If it is set, the "cooked" mode line editor will treat
> UTF-8 multi-byte sequences correctly. This mode can be set from
> the command shell with "stty iutf8". Xterm and friends should set
> this bit automatically when called in a UTF-8 locale.
But debian and upstream already set the line discipline properly
(even if the kernel console still have issues in debian because
of initscripts ordering, cf below).
Maybe it did not in 2002 ...

Just as a side note, there are still issue with utf-8 and
framebuffer console, but only due to a egg-chicken problem in
settings the correct mode in sysvinit scripts. The bug is already
filled there  and the issue is weel known so i don't assign those
bugs to it. 
BUt i don't think the kernel need to ad anything for utf-8
support , so i wonder if any utf-8 bugs are still relevant there
(maybe we need more utf fonts for the vga console but that is
another issue).


Reply to: