Now we turn to the syntax for redefining single keys or sequences of keys. This syntax has the following rules:
Each redefinition consists of a left hand side and a right hand side. The key(s) in the left hand side will be replaced by the sequence in the right hand side. The left hand side and the right hand side are separated by an equals sign (=). Both the left hand side and the right hand side must contain at least one key.
Each sequence of keys consists of single key codes, separated either by a plus sign (+) a comma (,), a tab or blank spaces.
Each redefinition is terminated by a semicolon (;).
Each single key code is a string of 8 hexadecimal digits. This is either a string that is an exact replica of the code that is given by stedi's keyboard handler when a character is read out (a must for the left hand side keys) or something that looks sufficiently like such a string that the keyboard processor of the editor will accept it for further treatment (right hand side). If this last condition is not met, the editor may not recognize what you want.
Linefeeds and carriage returns are seen as irrelevant. This means that one redefinition can run over several lines. The limit to the length of a redefinition is set to 509 keys. This limit comes from the buffer sizes in the program keycomp only. If it turns out to be a real problem the user could change the size of these buffers and retranslate keycomp. There is also a limit on the length of the whole redefinition ASCII file: the compiler must be able to read it in in a single read statement, so it must fit in memory. This should not be much of a limitation.
Two types of commentary are allowed. First, when the compiler runs into a colon (:) it considers any characters that follow as commentary until the terminating semicolon is reached. Second, any text between a matching pair of (any type of) brackets or parentheses is considered as commentary. The commentary isn't allowed to break up the field of the 8 digits. This commentary is very useful for noting what key a key code corresponds to. There are no escape characters inside the commentary so if this commentary is to include a `)' it cannot be enclosed between `(' and `)' but other types of brackets must be used.
Instead of the 8 character key codes a number of keywords is allowed. In addition single characters will also be translated into the appropriate 8 character hex code. The backslash serves as an escape character if any special character is to be used. This mode of using mnemonics and single characters is the preferred mode for writing readable key redefinition files, although sometimes one has to resort to the hex codes in the right hand side of the redefinitions and the left hand sides should nearly always use the 8 digit hex codes. We will see why.
The above specifications define the entire language used for keyboard reconfiguration. Most of the rest of this chapter is devoted to examples which will clarify exactly what the key codes needed for the redefinitions are, and how to use them. Should you want to relax some of the constraints on this language for your own personal use, the source code to the program keycomp (programmed in the C language) is included on the distribution disk, so you may make your own modifications.
Once the keyboard file is stored in stedi's buffer, whenever the editor receives a key code from the keyboard, it will work its way through the list of key redefinitions from the front to the back until it finds a complete match. No attempts are made to sort this list or to change the order in any other way. This allows for very tricky redefinitions. Of course, if no match occurs, then the normal action of that key code will be enacted. Beware though, in the case of actions assigned to multiple key strokes, the redefinition may preclude the possibility of using action assigned to a subset of such key strokes. This will be made clear in the following paragraphs. Now let's turn to some examples:
: Example 1: Some combinations of the left shift
key, the alternate key and function keys are used
to enter a number of blanks into the text;
0A000801(left-shift+alt+F1)=blank;
0A000802(left-shift+alt+F2)=blank+
blank: 2 blanks;
0A000803(left-shift+alt+F3)=blank+blank+blank;
0A000804(left-shift+alt+F4)=blank+blank+blank+
blank: 4 blanks;
: Etc. ;
In this first example, you see how a key redefinition statement looks. In this case, on the left hand side of each statement is just one 8 digit hexadecimal key code followed by some commentary explaining what key that code corresponds to. These codes stand for the successive function keys in combination with the left-shift and the alternate keys. On the right hand side in each case are one or more mnemonic codes which all correspond to the same key code - that for the space bar or blank space. Of course, the right hand side is much simpler than the left hand side. Typing the key codes at the left is not a very easy task, apart from the problem that one may not have documentation available containing these codes. Therefore stedi contains a special command, the Ctrl-K command. When the cursor is in the text window and the Ctrl-K is pressed, the cursor will vanish and stedi waits for the next key. The full code of the next key pressed will then be entered in the text. This holds for combination key codes using the shift, alternate and control keys as well. This key code is the code after the keyboard processor of stedi has processed it. If for some reason or another you would like to see the raw code of a key, as given by the operating system you may type Ctrl-J, followed by the key combination of your choice. The result is now system dependent and stedi won't recognize it any more. Sometimes it can be handy though for people who make software that is tailored to the possibilities of a specific keyboard.
The reason that we put the left hand side in terms of the cumbersome hexadecimal code is rather simple. This way it may contain full information about the shift, alternate, control and capslock keys. In addition we can make up our own keys as we will see in the sequel that there are several bits that can be used for flags and masking. At the right hand side we want to put some commands for stedi. This is then a much better defined set of codes, hence the practicality of using the mnemonics. If on the other hand we want to do fancy things on the right hand side one can also put the hexadecimal codes there. Similarly it is possible to use mnemonics in the left hand side.
If there are several redefinitions and some of them happen to have the same left side only the first one is effective. The redefinitions are stored in the same order as you have specified them. This can have unexpected consequences with redefinitions of more than on key at the left hand side.
: Example 2: The order of the keys
(What to avoid....);
04000247 (ctrl-G) + 00000072 (r) = .....
04000247 (ctrl-G) + 00000072 (r)
+ 00000065 (e) = .....
04000247 (ctrl-G) = .....
Of the above left hand sides only the first one is relevant. Once Ctrl-G
and an r have been typed the first redefinition will be executed. So the
second redefinition never gets a chance. The third one won't do anything
either: After a Ctrl-G has been pressed the editor runs into the Ctrl-G
+ r redefinition and decides to wait in order to see whether there will
be more. After the next character there are two possibilities: (i) it is
the character r and there is a match. (ii) It isn't an r and the search
goes on further through the table. But because we have now two
characters in the buffer it cannot match a single character sequence
any more. So number three cannot match.