Doug Ewell wrote:
Robert Finch wrote:
'm trying to implement a Unicode keyboard device, and I'd rather have
keyboard processing dealing with genuine Unicode characters for the
cursor keys, rather than having to use a mix of keyboard scan codes
and Unicode characters.
This will quickly spiral out of control as you move past the "easy"
cases like adding character codes for cursor control functions.
the "easy" cases like adding character codes for cursor control functions are not so easy when you have a short phrase or R-text (Right-to Left) embedded in a line of Englisch (L-text).
I think it is an acceptable solution at present (only a temporary implementation or solidified standard (?)) that the R-arrow will move through such a line of L-R-L mixed unicode text from Left, = Start of line, to Right, = logical End of text, passing the R-text in the correct logical order from its Right beginning to its Left end to continue past its Right in the usual manner. I would not like to give up this repeat-key action!
If the text-program forces somehow the visually correct RtL direction on the L-arrow which is logically toward the logical end, while over R-text it would have a problem at the L-END of the R-Text, moving on to the visually next L-text it would continue in the logically prossibly not intended direction to its beginning. The R-arrow with cursor at the L-start of R-text should move the cursor visually correct to the beginning of the rest of L-text or logically correct to the previous L-text?
I guess this ambiguity of intention let the text-programs provide LtR and RtL entry of text only to be changed for a whole paragraph. But that has presently undesirable effects on a mixed-direction line: L-jutified text becomes R-justified and sometimes the R-text moves into unexpected places. I am glad I don't have to make this switch (interrupting touchtyping twice in one line).
Thinking of the horizontal arrow-keys as logically previous and next helps.
Same for BS-erase and Del ('character under the cursor' is outdated, since the
cursors usually are seen between characters nowadays.What about Shift and Caps Lock? That would make text representationMSKLC .exe helps to create your own keyboard-layout, and provides with the 'Swiss-German' keyboard the opportunity to assign to the 'normal' keys quite a few extra symbols in CAPS-mode. I think such keyboard-layouter should provide the possibility to make your own choice on how the arrow and other controll-keys behave for your own keyboard layout.
ambiguous; you don't want an 'A' created by pressing the A key while
holding Shift to be different from an 'A' created by pressing A with
Caps Lock enabled. (How would you represent "enabled"?)
Besides the directionally neutral SPace in Unicode, we need either a standard for text-programs, that forbids SPace after R-text to make the cursor jump past the R-beginning of R-text assuming that L-text will follow. I find it extreemly irritating if this happens before I have swiched to L-text-entry. New Unicode characters of explicitely directional R-, L- and or PDF-SPace would solve my problem with the present layout-possibilities. This would not be control-codes, because they would have not only a visual effect on the cursor, but rather would provide a way to disambiguate the neutral SPace.
MSKLC.exe should provide key-assignments to e.g. seldom-used combinations of the F1..F12, Num- and Scroll- Lock-key with e.g. AltGr so select other keyboardlyouts and languages. I do not see how it could solve the above bidi-space-cursor problem without unidirectional SPace-code.
If you want to use characters to accomplish cursor control, you really
should take a look at the ECMA standard mentioned above.
And how can MSKLC or you make the keyboard generate the desired control ?
Peter R. Mueller-Roemer
