Xref: utzoo comp.emacs:6662 comp.sources.d:3962 Path: utzoo!utgpu!watmath!iuvax!purdue!mentor.cc.purdue.edu!j.cc.purdue.edu!nwd From: nwd@j.cc.purdue.edu (Daniel Lawrence) Newsgroups: comp.emacs,comp.sources.d Subject: Re: MicroEMACS 3.10 bugs, fixes and a MAJOR improvement to file completion Summary: Emacs Bugs Keywords: uEMACS 3.10 Message-ID: <9847@j.cc.purdue.edu> Date: 14 Aug 89 18:02:53 GMT References: <234@insyte.UUCP> Reply-To: nwd@j.cc.purdue.edu (Daniel Lawrence) Followup-To: comp.emacs Organization: Purdue University Lines: 75 In article <234@insyte.UUCP> m2@insyte.UUCP (Michael J. Arena) writes: >I like MicroEMACS 3.10. I am impressed with the level and scope of portability >that has been achieved. However, I have a few complaints and fixes: >1) mlwrite() in display.c tries to do its own variable argument parsing based >on STACK_GROWS_UP. This is ridiculous. Of all the systems I've ported this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >to (HPUX, VMS, SUNOS4, APOLLO, MSDOS), every one had and some >handled the stack in strange ways (especially RISC machines and alignment). >If you have a standard facility, then use it. Indeed, if I did, I would. However, as you pointed out, this works on the systems YOU ported it to. However I support uEMACS on a number of systems and compilers that do not have varargs.h, and I do not want to simply tell a lot of users there machines must be updated or changed because of this. >2) The file char.[co] seems to be left out of several makefiles. A minor nit >but I would have assumed that these makefiles were tested. Again... supply me with all those machines, and I will happily test all the make files. Unfortunatly, no one person can own all the equipment to do this. I have to rely on the users whe recieve the first draft release to help me with this. >3) The VMS DESCRIP.MMS is referencing SMG.OBJ and VMSVT.C. Where are these? >It seems that VMSVT.C was incorporated into VMS.C but the SMG stuff is nowhere >to be found (VMS4.7, VAXC2.3). Again, it is my lack of a VMS machine. It has already been noted, and the people at DEC and in Chicago and here at Purdue whom normally help with the VMS work have gotten together and got both the ANSI and SMG support packages working. They will be included in the next intrim release. (No time promises. I do this in my spare time for fun). >4) The file name completion routines were amazingly inefficient. It actually >rescanned the entire directory for each CHARACTER that matched even if there >was only one matching entry. Also, it would not complete directory names >which mostly defeats the purpose of the function. The fixes below permit >directory names to be completed and will scan a directory ONCE. While >scanning, the longest possible match is remebered. If the match is a >directory, then the DIRSEPCHAR is appended. I agree here... my original goal was to have one set of completion routines for all 3 different types of completion. This brought the consistancy of completion up, and the size down. Unfortunatly the directory scanning is very expensive... I have already coded a very simple cashing for this that will allow me to use the same code still. >5) For tcap.c, it was a good idea to have function key parsing that >standardized the names. However, it is now quite difficult to deal with >application keypads. I use a VT100 like terminal with 8 function keys >and an 18 key keypad. Most of the keypad is wasted since a standard termcap >only allows for 10 function keys and a few special keys like delete character, >page up/down, etc. I can't think of a solution so maybe I shouldn't complain. Someone.... send me a VT100! >Below are the 2 functions in unix.c which were changed. Following these >is the comp_file() function in input.c. Thanx for the code.... I will try to extract code to let us scan directory paths from it. >Michael J. Arena (617) 965 8450 | UUCP: ...harvard!linus!axiom!insyte!m2 >Innovative Systems Techniques | ...harvard!necntc!lpi!insyte!m2 >1 Gateway Center, Newton, MA 02158 | ARPA: insyte!m2@harvard.harvard.edu Daniel Lawrence voice: (317) 742-5153 arpa: dan@midas.mgmt.purdue.edu The Programmer's Room Fido: 1:201/10 - (317) 742-5533