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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
