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
quit
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
responsability.
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)
http://bugs.debian.org/139771
http://bugs.debian.org/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 :
http://bugs.debian.org/163031
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).
Ciao
Alban
Reply to: