wsincc@eutrc3.urc.tue.nl (Wim van Dorst) (06/21/89)
Dear Everybody,
From all the reactions I got on my mail to comp.emacs, stating
that I couldn't get MicroEmacs 3.10 to compile and run properly
under VMS, I have the impression that the official release 3.10
is somewhat faulty. So I consider this an official bugreport. If
Mr. Lawrence and friends pay some attention that is fine with me.
For completeness: I werk on VMS4.7 on a VS2000 Digital
Workstation. Right. There were a few small bugs in the files
edef.h, main.c, meshr.opt and vms.c, namely
Oops 1: In edef.h cname is defined for main as
CONST char *cname[], Furtheron in edef.h cname is defined
for all other files as NOSHARE extern CONST char
*cname[]. I have changed this in CONST extern char
*cname[] because NOSHARE and extern together cannot be.
Oops 2: In epath.h pathname is defined as ... *pathname[]. In
main.c as extern ... pathname[]. For obvious reasons I
added the * for the pointer in main.c
Oops 3: I have added char.obj to the file meshr.opt, because
it contains some essential functions like isupper().
Oops 4: Not a genuine bug, but a (needed) addition. In the file
estruct.h I (hopefully) set the option COMPLET t01, until
I read in the manual there is no filename completion yet
for VMS. So I reset it to ), but then also command
completion didn't work anymore, which I often use.
Therefore I set COMPLET to 1 in estruct.h and added empty
filename completion functions in vms.c, such as:
char * getffile() { return NULL; }
char * getnfile() { return NULL; }
See for some explanation in history.c.
Oops 5: The function keys, my last problem, now solved.
In vms.c the function vmsqin() is use for storing
characters in an inputbuffer. vmsqin() takes a char (one
byte in VMS) as argument. The function vmsgcook() tries
to uses vmsqin() to fill the inputbuffer with proper
values, according to which keys has been typed. When an
escape sequence from a function key is encountered
vmsgcook() cooks it and places the proper bytes in the
inputbuffer by means of vmsqin(). First it does vmsqin(0)
to indicate escaping, and then it want to feed vmsqin()
an int, holding the (nearly good) information. Of course
the upper byte gets lost, and function keys are not
recognised. So I split the int in two parts and then
supplied them to vmsqin() which works fine.
Then I noticed the SPEC bit is not set anywhere. It
should be done in vmscap() where all the function keys
are added to the key map table, but being a lazy typer
I added it in this same statement instead of in each key
definition in vmscap().
Thus my solution to get the function keys going is in
file vms.c in function vmsgcook() change the call
vmsqin(cur->code);
to
vmsqin((SPEC | cur->code) >> 8); /* upper byte */
vmsqin(0x00FF & cur->code); /* ascii byte */
This did the trick for me.
I hope other people may find my changes with the explanations
useful. If you have any questions (or remarks) feel free to
e-mail to me or comp.emacs. With many kind greetings,
Wim van Dorst, wsincc@eutrc3.uucp
ps Mr Lawrence:
Being a little proud of these solutions (I'm just an amateur)
would you be so kind as to put my name in the history lists?fritz@unocss.UUCP (Tim Russell) (06/23/89)
Amazing! Tom Davis and I here at UNO just fix the exact same bugs, and I
was about to post them! Thanks for saving me the typing! :-)
I'm going to work on filename completion, it shouldn't be that difficult.
Also, there's one more NASTY bug: emacs doesn't create a new version of the
file when you edit it, it works on the current one. I'll be working on that
as well. Also pipe-command, which will be fairly easy, I think.
--
---------------------------------+--------------------------------------------
Tim Russell, Computer Operator | Internet: russell%zeus@fergvax.unl.edu
Campus Computing | Bitnet: russell@unoma1
University of Nebraska at Omaha | UUCP: uunet!zeus.unl.edu!russellwallace@leddev.dec.com (Ray Wallace) (06/24/89)
In article <877@unocss.UUCP>, fritz@unocss.UUCP (Tim Russell) writes... >Also, there's one more NASTY bug: emacs doesn't create a new version of the >file when you edit it, it works on the current one. That's not realy a bug but a new feature of 3.10, on VMS you should have the following line in your EMACS.RC file, set $ssave FALSE ;Otherwise all old versions of files will be deleted On computers which do not have multiple versions of files you should leave $ssave set to TRUE (the default) as it provides some bit of recovery if things go wrong (ie: system crashes). If $ssave is TRUE, whenever you tell MicroEmacs to write out a buffer it will write it to a temporary file, delete the original (that includes all versions of the file in VMS), then rename the temporary to the real file name. --- Ray Wallace wallace@leddev.dec.com --or-- ...!decwrl!leddev.dec.com!wallace --or-- wallace%leddev.dec@decwrl.dec.com ---