whm.arizona%Rand-Relay@sri-unix.UUCP (10/20/83)
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!whmthomas%UTAH-GR%utah-cs@sri-unix.UUCP (10/21/83)
From: thomas%UTAH-GR@utah-cs (Spencer W. Thomas) Just a few random remarks on your comments about Unipress emacs. I think the first release is basically just as they got it from Gosling. Hopefully, they will clean it up a bit in the future. It was announced on Unix.Emacs that the name of the error-occurred function was changing (at least I think it was, maybe that was private communication with jag), in any case, it is pretty simple to write a shell+sed script to fix all your .ml files at once. Nobody uses the file name completion (that I noticed), all you get is the get-tty-file function, it's up to you to use it. (Or were there some top-level functions in the mlisp?) That problem with 200 character buffers has been in there just FOREVER - for longer than we've had emacs, anyway. One of these days I may get the energy... Re: your key binding idea. What about a function which is bound to more than one key? Which key do you pick? BTW, I've got some significant bug fixes for #264, including a couple nasty ones in the compiler. If you ever want to bind ESC-^@, you need these. =Spencer
phil.rice%Rand-Relay@sri-unix.UUCP (10/21/83)
From: William LeFebvre <phil.rice@Rand-Relay>
"Nobody uses the file name completion (that I noticed), all you get is
the get-tty-file function, it's up to you to use it."
When was the last time you used "visit-file"? It most certainly uses
file name completion. File name completion is one of the handiest
things I have ever used. As my dad would say: "It's the greatest thing
since popcorn"!
I'm sure that there are several other wired functions that use file
name completion in #264 (such as "read-file", "insert-file" and
"unlink-file") and it's easy to change most any MLisp function that
doesn't use it when it asks for a file name. Just replace
"get-tty-string" with "get-tty-file".
William LeFebvre
ARPANet: phil.rice@Rand-Relay
CSNet: phil@rice
USENet: ...!lbl-csam!rice!philthomas%UTAH-GR%utah-cs@sri-unix.UUCP (10/23/83)
From: thomas%UTAH-GR@utah-cs (Spencer W. Thomas) I stand corrected. Guess I was fooled by the fact that the file-name completion was not mentioned anywhere I could find it in the manual. I just dropped it into our already existing mlisp functions. =Spencer (BTW, has anybody else noticed the large number of unknown addressees on this mailing list?)
whm.arizona%Rand-Relay@sri-unix.UUCP (10/24/83)
I've gotten some feedback on my comments and would like to add a few comments. It's been about six months since it was announced that UniPress was going to be distributing Emacs and I would have hoped that in that time, they would have made some moves towards cleaning up the documentation and MLisp packages. It seems like what they're doing is just selling it as-is. The package they distribute (not counting the editor itself) seems closer to what I'd expect from a "send me a tape and I'll send you a copy" sort of distribution. UniPress is advertising Emacs in magazines; that says to me that they must think what they have right now is in fine shape. Wrt. to the 200 character buffer problems: Doesn't it seem like that should be mentioned somewhere? Seems like a pretty severe restriction to me. (200 characters is not my idea of a huge string!) As several people noted, surjective key to function relations do present a problem to key-binding-of. How about a function that takes two functions (a and b), and for each key that is bound to a, establish a local binding to b. For example: (local-copy-bindings "self-insert" "funky-insert") Several have said that load doesn't use file name completion because it uses a search path to locate files. I don't quite see the problem with this. Sure, the semantics get tricky when you're dealing with a list of directories, but the name completion doesn't need to always be used does it? I wrote: (defun (Load (load (get-tty-file ": Load ")))) and it does what I want. I just don't see the problem. If I want it to go searching along EPATH for foo.ml, I can Load foo, and if I want to load $elib/foo, I can do that as well. In response to my query about sites where Emacs is the dominant editor, I did turn up several such sites. One other thing, I sent UniPress a letter (via USmail) at about the same time I posted my original "our new Emacs" message. I'd encourage other people to do the same if they aren't satisfied with the way things seem to be going. Bill Mitchell
preece@uicsl.UUCP (10/28/83)
#R:sri-arpa:-1282000:uicsl:21900002:000:591 uicsl!preece Oct 27 10:12:00 1983 I could be wrong (I haven't looked at sa figures for some time), but my impression is that emacs is used here more than vi. I suspect that this reflects the nature of our users (lots of grad students) and that when we switched to the Vax there were people here with knowledge of Emacs, so that it got plenty of attention when people were making their choice. As to documentation, I didn't find the vi documentation the most useful thing I've ever read, either. I do wish it didn't take so much longer for Emacs to start up than for vi to start up. scott preece ihnp4!uiucdcs!uicsl!preece