-*- mode: outline -*-
2.4.22-std-up-alt17

* First patch - patch-cons-resp-2.3.12 adds to console driver following features:

** possibility to cut/paste using selection between ASCII and UTF console
   absolutely free. With this patch you can cut in ASCII, paste in ASCII
                                                   UTF             ASCII
                                                   ASCII           UTF
                                                   UTF             UTF

Test: opened 4 login sessions; set up them by either `LANG=<..>.UTF-8;
unicode_start;' or `LANG=ru_RU.KOI8-R; consolechars -m koi8-r;'
(Unicode was stopped before). Then output some sequuence of
Russian/English words according to the locale (e.g., `dict pay').
Test with gpm.
The results do not depend on which exactly
console is used or what is the language (ru or en):
cut in ASCII, paste in ASCII   OK
       UTF             ASCII   OK
       ASCII           UTF     FAILED
       UTF             UTF     FAILED
(I'm using SYSFONT=UniCyr_8x16)

*** Related issue: gpm doesn't know the correct bounds of Russian words
(either in koi8-r or utf-8 console); example: pereimenovat', 
'v' is treated as the boundary.


** you can use only one keyboard map for UNICODE & XLAT mode (keyboard
   map with Unicode definitions. In XLATE mode it translates to ASCII
   automatically)

Test:

In the setup of the previous test: 

1) `loadkeys ruwin_ct_sh-KOI8-R' which is an 8-bit map. Input in
KOI8-R consoles is OK, in UTF-8 generates no visible
output (FAILED). (Remember, the keymap is shared between all consoles.)

2) After 1), 
`{ echo 'charset "unicode"'; dumpkeys --charset=koi8-r | tail +2; } | ./loadkeys' 
(which loads the cyrillic keymaps as Unicode -- they were in koi8-r
before; 
this can be done by loadkeys  from kbd-1.12-1 Debian pkg.) Input in
UTF-8 consoles is OK, in KOI8-R generates 2-byte UTF seqs (FAILED)


** ESC7/ESC8 save/restore saves also utf mode flag. So programs like showfont
   now can restore console state correctly.

Test: Well, showcfont seems to be too intelligent to be a test.
Try in KOI8-R: `echo -ne '\e7\e%G\e8'; dict rename'
You won't get it in the right state afterwards (to read dict's
output). So, it is not saved (FAILED). Also: 
`echo -ne '\e7\e%@\e8'; dict rename' FAILED in the UTF-8 console.

Probably, applying this patch will mean
also a patch for /usr/share/man/man4/console_codes.4.gz
(man-pages-1.66-alt1) to reflect the new more complete behaviour.


* The patch below improves the behaviour of the keyboard input method in
Unicode mode:

**  1. It permits to use the CapsLock behaviour (denotes by a '+' sign in
     the keymaps file) for Unicode values (for example German umlauts -
     they cannot use the normal KT_LATIN/KT_LETTER mechanism in Unicode
     mode).

(This is done by using the yet not used private Unicode zone. But it
is a bit small to allow to make *all* symbols capslockable, but those
left outside are very far, starting from the middle of CJK ideographs
zone. As to me, this is not an actual problem.)

Test: The same setup as in 2) in patch 1 part 3: the loaded keymap has
+cyrillic_small_letter_tse, +cyrillic_capital_letter_tse, +w, +W. But
Caps_Lock works correctly only with w/W, not tse/Tse (they remain
unaffected by its state). FAILED

**  2. It avoids buggy behaviour when CapsLock is active and a key is
     pressed whose standard mapping is KT_LATIN but whose Shift mapping
     is Unicode.

Test: In the setup of 2) in patch 1 part 3:
$ loadkeys
charset "unicode"
keycode 17 = +w +cyrillic_capital_letter_tse
$ 

pressing a w S-a S-w generates: a w A Tse (OK)
pressing <CAPS> a w S-a S-w gens: A w a Tse (FAILED)

**  3. It permits Unicode keymaps to access the U+f800..U+ffff Unicode range
     which was previously inaccessible due to the way keysyms are
     represented in the kernel.

(Well, this doesn't seem to be important because AFAIK U+f000..U+ffff
is for private assignment, which is not quite useful. (In fact, they
ARE privately assigned by the kernel drivers the special meanings.)

Test: same setup.
$ loadkeys
charset "unicode"
keycode 17 = U+ef00
$ echo -n <Press w> | hexdump
shows smth.

But: 
$ loadkeys
charset "unicode"
keycode 17 = U+ff00
$ echo -n <Press w> | hexdump
shows nothing (FAILED)

**  4. It resets the kbd->slockstate when a Unicode key was hit, just the
     same as is done for KT_LATIN mapped keys.

Test: same setup.
$ loadkeys
charset "unicode"
keycode 58 = SShift SShift
keycode 17 = +cyrillic_small_letter_tse +cyrillic_capital_letter_tse
$ 
Press: a S-a a <CAPS> a a w S-w w <CAPS> w w a a
Generates: a A a A a tse Tse tse Tse Tse A a
FAILED
Expected:  a A a A a tse Tse tse Tse tse a a

* The patch below fixes the "cooked" mode editing behaviour of ttys in
Unicode/UTF-8 mode. The line editor in n_tty.c up to now assumes that
every byte >= 0x20 is a character and occupies one screen position. For
ttys in UTF-8 mode, this is not true any more. The patch fixes the two
following problems in line editing on UTF-8 ttys:

**  1. When the user types BackSpace, a multi-byte character has to be
     erased, not only a single byte. Also, in ECHOPRT mode, the entire
     multi-byte character has to be echoed to the screen, not only one
     byte.

Test: 1) linux console. same setup for UTF.
$ cat
<Press g C-S zhe C-S g BS BS BS Enter>
<We see g on the next line; expected nothing.>
FAILED
 2) Same test, preceded by `stty echoprt'. Will not print zhe between
 \/, although it should.
FAILED

3) xterm in X started by the UTF-8 user, `-font -val-*-iso10646-1'
same results for both tests FAILED

**  2. When the user types a Tab or backspaces over a Tab, the kernel
     needs to have the proper notion of the column number of the cursor
     (tty->column). For a multi-byte character, the column number increases
     by 1, not by the number of bytes that make up the character.

Test: 1) linux console. same setup;
$ cat
<Press k C-S zhe C-S k TAB k BS BS>
<We see cursor on the pos next to the left of k: k_#; 
expected: to left of k: k#.>
FAILED

2) xterm in X started by the UTF-8 user, `-font -val-*-iso10646-1'
same results FAILED

** The program which sets up the tty (xterm, rlogind, telnetd etc.) has to tell
the kernel that it the tty will be in UTF-8 mode. For this purpose, a new
tty attribute is introduced, part of the "struct termio" structure.

A patched package of coreutils (include stty) has been made. 

TODO: put the new option into man-page termios(3).