rickm@oregon.uoregon.edu (Rick Millhollin) (12/27/90)
(Sorry about the empty posting, don't know what happened there, so let's try that one again!) I recently built MicroEMACS 3.10 for VMS, and all works well except the cursor and function keys on the VT200/300 keyboard. These terminals are in my SMG tables, and I know that the proper SMG-based VMS terminal I/O functions got linked. Is there some other trick to this that anybody out there can help me with? Also, is the MicroSCRIBE used to format the maunal EMACS.MSS available?
davidm@uunet.UU.NET (David S. Masterson) (01/01/91)
>>>>> On 26 Dec 90 19:54:36 GMT, rickm@oregon.uoregon.edu (Rick Millhollin) >>>>> said: Rick> I recently built MicroEMACS 3.10 for VMS, and all works well except the Rick> cursor and function keys on the VT200/300 keyboard. These terminals are Rick> in my SMG tables, and I know that the proper SMG-based VMS terminal I/O Rick> functions got linked. Is there some other trick to this that anybody Rick> out there can help me with? I haven't worked with the sources for MicroEMACS 3.10 yet, but I have worked with MicroEMACS 3.9e on various platforms (including VMS). Assuming there isn't much of a difference and you're willing to do some investigation, perhaps I can offer an idea on where to look. As far as I can tell, the SMG routines (which I don't really understand myself) are only minimally used in the code (for compatibility across platforms). In particular, the 3.9e code itself supports very little beyond the standard VT100 codes for function keys and arrow keys. The code for converting keypresses into actual command sequences was in INPUT.C. Using ^Q (quote-character), run through the cursor and function keys on the VT200 keyboard to produce yourself a table of equivalents (something like "ESC [17~" == F6). This will give you an idea of what EMACS is seeing the keys as. Inside INPUT.C are two functions -- get1key() and getcmd(). In particular (if it hasn't moved), there is code in getcmd() to handle VT100 special codes. This code will get1key(), note that the key is an ESC (CTRL | '['), then try to translate the ESC key plus the following key(s) into a single keypress that can be used later to index into a list of commands. I believe that the standard code merely looks for sequences of the type ESC[x (which should be the PF keys on the VT100). Your job is then to modify getcmd() to translate (mathematically) the next 1 to 3 keys following an "ESC[" or "ESCO" and ending at a "~" into a unique number that can be OR'ed with SPEC and not have the result conflict with other SPECial keys on the keyboard. As it turns out, if the first key following the open sequence is an alpha, then it will be the only thing in the sequence (standard PF keys). If, however, the key is an integer, then there maybe more integers in the sequence that terminates at the "~". Take that into account in your code. I maybe completely off in this, though, as I believe this is one area that Dan wanted to make significant changes to for 3.10. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
rickm@oregon.uoregon.edu (Rick Millhollin) (01/03/91)
Thanks for the many responses to my plea for help! It turns out that there is a simple two-line fix to VMS.C that will cure the problem. Here is the DIFF: ************ File SYS$AUXDEVICE:[RICKM.EMACS]VMS.OLD_C;1 491 nxtkey->code = fn; 492 ****** File SYS$AUXDEVICE:[RICKM.EMACS]VMS.C;1 491 nxtkey->code = SPEC|fn; 492 ************ ************ File SYS$AUXDEVICE:[RICKM.EMACS]VMS.OLD_C;1 904 vmsqin(cur->code); ****** File SYS$AUXDEVICE:[RICKM.EMACS]VMS.C;1 904 vmsqin(cur->code >> 8); 905 vmsqin(cur->code); ************