Re: Improved console UTF-8 support for the Linux kernel?

[Jan Engelhardt]

>I am a bit confused. Could you please comment on the following, as a
>common test steps?

I do it a bit faster (i.e. without "od"): if after a Compose operation, I see 
something, it must have been UTF8. If not (like there has been only 8 bits 
output), the current line screws up a little. <- My test strategy; does not 
need `od` to confirm.

>I am not sure how you wrote the above characters. According to UTF-8,
>characters with codepoints above 0x79 require two bytes so that to be
>valid. When you compose "Ã" (you press something like ";", then "o") in
>the console?

à is a "native key" on my keyboard, i.e. i do not need to play with compose to 
generate Ã.

>For simplicity, let's assume you do something like
% loadkeys --unicode
compose '/' 'e' to U+00F6 # ('Ã')
^D
% 

I did that (a shortened form of yours), and saw by `dumpkeys` that there was 
now only one compose table entry, so I think `loadkeys --unicode` overwrites 
the table? Rightly so.
Still and despite there are now no compose table entries, with the exception of 
that one, I can still generate Ã. <compose><"><o> rightly gives two 7-bit 
characters (rightly so at this point).

>Good. I hope more people raise their hands for this.

...want kanji-on-console, but I guess that will not come true with VGA, which 
only supports 256 (512) chars. OTOH, [free]BSD's mouse support uses a graphical 
mouse pointer rather than a "block" one like gpm does, and as I think of it, 
such a graphical mouse (most Norton apps for DOS also had such) needs some VGA 
magic or so to set single "pixels"/bits. If single bits within the 8x{16,etc.} 
char cell can be set, we could have kanji.
Can anyone elaborate on this graphical mouse stuff?



Jan Engelhardt
-- 
ENOSPC