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