Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!whm.arizona@Rand-Relay
From: whm.arizona%Rand-Relay@sri-unix.UUCP
Newsgroups: net.emacs
Subject: our new Emacs
Message-ID: <12820@sri-arpa.UUCP>
Date: Thu, 20-Oct-83 05:43:40 EDT
Article-I.D.: sri-arpa.12820
Posted: Thu Oct 20 05:43:40 1983
Date-Received: Wed, 26-Oct-83 03:00:53 EDT
Lines: 100

We recently purchased a copy of UniPress Emacs and I thought I'd share
a few comments with the group.

First of all, I was really disappointed with the state of the documentation.
The installation instructions haven't changed much in the last couple
of years and on top of that, they still have some errors.  There were
rumors of UniPress doing a new manual, but the one supplied just seems
to be a reorganization of the old one with a few new things added.
Also, the manual still contains a load of spelling errors, typos and
the like.

I also had high hopes that UniPress had spent some time on cleaning up
the MLisp packages, but of the twenty-odd packages, I discovered
glaring problems in seven of them during a cursory testing session to
ensure that the system worked.  My favorite bug is one in info: You
run info, it instructs you to type an "h", you do so and get to a node
where it says to type "N" to go to the next node.  You type an "N" and
it beeps (or blinks).  The secret is to use lower-case characters
instead of upper-case, but that wasn't immediately obvious.

In the previous version of Emacs that we had (#85), there was a function
called "error-occured".  In #264, the function "error-occured" has
been replaced by "error-occurred".  While I realize that it's probably
not reasonable to expect UniPress to provide compatibility with pre-
UniPress versions of Emacs, and while I realize that whoever made the
change probably did some deliberation as to how to solve such a sticky
problem, I think that some sort of prominent notice of the change would
have been in order; every MLisp program in the house broke.  I ended
up fixing this by adding "error-occured".  It is also interesting to
note that the "Occurances" command is still with us.

Another cutie in the compatibility line is that #85 accepts (e.g.)
	(bind-to-key "backward-char" ...)
as being valid because "backward-char" is a unique prefix of a command,
but this fouls up #264.  I imagine that #85's behavior in this respect
was accidental, but again, some notice of the change would have been
nice.

The file name completion stuff is very nice.  However, the load function
doesn't use it?  Is there some reason for this?

Here's a real killer.  If you make a string that's >~200 characters
long and have its value displayed in the minibuffer, Emacs exits (or
tries to).  A look at the code reveals an array of 200 characters that
is apparently being overrun.  I've been prowling around in the Emacs
source code for the last couple of days (for a project) and there seem
to be several places where it is assumed that MLisp strings are never
more than 200 characters long.  Is this some sort of unwritten law?
The only mention of string length restriction that I can find is an
admonition in the documentation for region-to-string to not use "huge"
strings.

I have a creeping suspicion that Emacs sometimes doesn't free storage
when it should, but I have no solid evidence.  I often see my #264 grow
to 700+ pages (on a VAX), but it seems like #85 usually stayed well
below 500 pages.

Now a suggestion about key bindings in MLisp packages.  I've rebound
almost the entire keypad and whenever I go to use a "standard"
MLisp package I'm consigned to revert to the standard bindings
or make a personal copy of the package and hack up the bindings.
A reasonable solution to this problem (this may well have been
suggested before) seems to be to not use constant values for
the various local key bindings that the packages do.  There seem
to be two alternatives:  Use variables to contain a certain
set of bindings for various keys, e.g.
	(setq NextLine "\^n")
is the standard, and a package might use a binding like:
	(local-bind-to-key "next-item" NextLine)
Or better yet, make a function that returns a string representing
the key sequence a function is bound to.  For example:
	(local-bind-to-key "next-item" (key-binding-of next-line))
Thus, people who wish to rebind keys aren't murdered when they want
to use a package.  The documentation can talk in terms of operations
rather than specific characters.

Several other people have made suggestions about ways to improve
MLisp packages; one of the suggestions that I liked a lot was that
of each MLisp package optionally calling some function to perform
per-user "customization".  The problem with all such suggestions
is that of acceptance and usage.  Right now, UniPress is in a position
where they can influence standardization and increases in quality of
MLisp packages; I hope they make some moves in this direction in
the future.

In summary, I'd say that #264 is a substantial improvement over #85
where the editor proper is concerned, but the documentation and MLisp
packages have changed only slightly.

Along a different line...I've been at two installations where Gosling's
Emacs was (is) available.  At both, Emacs was somewhat of a cultish
item with (I'd guess) less than 10% of the user population using Emacs.
Are these two data points out of the mainstream, or is this the
case at many installations?  Are there any sites where Gosling's Emacs
is the dominant editor?  My hypothesis is that the quality of
documentation is serving as a barrier to widespread use and acceptance.

					Bill Mitchell
					whm.arizona@rand-relay
					{kpno,mcnc,utah-cs}!arizona!whm