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
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: Re: our new Emacs
Message-ID: <12948@sri-arpa.UUCP>
Date: Mon, 24-Oct-83 06:01:46 EDT
Article-I.D.: sri-arpa.12948
Posted: Mon Oct 24 06:01:46 1983
Date-Received: Thu, 27-Oct-83 22:47:10 EDT
Lines: 45
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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!seismo!harpo!decvax!ittvax!sii!mem
From: mem@sii.UUCP (Mark Mallett)
Newsgroups: net.emacs
Subject: Re: emacs usage
Message-ID: <332@sii.UUCP>
Date: Mon, 31-Oct-83 22:07:12 EST
Article-I.D.: sii.332
Posted: Mon Oct 31 22:07:12 1983
Date-Received: Fri, 4-Nov-83 02:54:45 EST
Lines: 17
b
On the VMS (VAX 11/780) system that I use, almost all of the users came
from a DEC-20 and there is a widespread sentiment that "I'd love to use
EMACS if only we had it". Well, we do have it; but users can run it
only if they manage to discover its presence serendipitously. The
system manager has, probably rightly, elected NOT to publicize its
existence because it is NOT supported, nobody knows much about it
(including where it came from; ergo where to get assistance from),
and mostly because it has abysmal documentation.
I realize that this doesn't relate to "emacs vs. vi". Btw.. what
about vms emacs? anybody out there have any involvement with it?
Myself? I use emacs. But then again, the alternative is EDT.
Mark E. Mallett
decvax!sii!mem
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!kobold!tjt
From: t...@kobold.UUCP (T.J.Teixeira)
Newsgroups: net.emacs
Subject: Re: EMACS Usage
Message-ID: <190@kobold.UUCP>
Date: Tue, 1-Nov-83 10:24:34 EST
Article-I.D.: kobold.190
Posted: Tue Nov 1 10:24:34 1983
Date-Received: Fri, 4-Nov-83 07:17:29 EST
References: <6010@cca.UUCP>
Organization: Masscomp, Littleton, MA
Lines: 38
This is in reference to Steve Zimmerman's comment on editor usage at
CCA, and in particular the comment:
Gosling's EMACS is available on both VAXes, but nobody uses it.
It is very seldom that an editor gets to be the dominant editor on a
system because all the users have tried all the alternatives and made
their choices accordingly. Rather, most people will use the editor
that is best supported. If you go to your local guru and ask a
question about vi, and he answers: "I use EMACS, not vi! You'll have to
figure that out yourself.", how long will you continue using vi?
On system which have sizable user communities for different editors,
the editor usage usually closely matches some other division within a
larger organization. For example, on some of the PDP-10's at MIT, the
CLU people tend to use TED (a screen editor written in CLU) rather than
EMACS. On one of the VAX's at MIT, most people use Gosling's EMACS,
even though an older version of CCA EMACS is available as well as EE,
another local variant of EMACS. This is true even though CCA EMACS and
EE are closer to PDP-10 EMACS. Why? Partially, for technical reasons,
but mostly for historical -- we got Gosling's EMACS first, and the
system maintainers and older users know it. That is what is introduced
to new users. The community of users for EE mainly consists of people
who also use either a PDP-11 or the MIT-NU terminals (a 68000 system).
This reflects the fact that Gosling's EMACS didn't run very well on
these systems (at least when it was first tried), but EE does. These
people use EE on the VAX because then they can use the same editor on
all their machines.
In all this discussion, I'm reminded of the time that DEC gave a talk
at MIT when the VAX-11/780 was announced. One of the first questions
was whether TECO would be available. The response:
Text editors are like religons --
only people are more fanatical about text editors!
--
Tom Teixeira, Massachusetts Computer Corporation. Littleton MA
...!{harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 486-9581
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!decvax!cca!z
From: z...@cca.UUCP (Steve Zimmerman)
Newsgroups: net.emacs
Subject: Re: EMACS Usage
Message-ID: <6027@cca.UUCP>
Date: Wed, 2-Nov-83 12:41:38 EST
Article-I.D.: cca.6027
Posted: Wed Nov 2 12:41:38 1983
Date-Received: Sun, 6-Nov-83 05:30:37 EST
References: <6010@cca.UUCP> kobold.190
Lines: 50
Tom Teixeira says "Most people will use the editor that is best
supported." I fully agree. However, the implication is that
significantly more effort is put into supporting CCA EMACS at CCA than
is put into supporting other editors. This is not the case. Very
little active support is put into any of the editors in terms of helping
users on a one-to-one basis. Instead, it is the support that comes with
the editor that is important. Both the Rand editor and vi come with
reasonable documentation, which is one reason they both developed a fair
following. As CCA EMACS is a much more complex editor than either of
those two, its documentation is correspondingly more extensive,
including a 235 page manual, an online tutorial that assumes no previous
knowledge of text editors, and many other online help facilities.
Certainly this type of support was instrumental in the acceptance of CCA
EMACS here. Without it, there would have been no way that CCA EMACS
could have been introduced as the standard editor for secretaries,
managers, and our text editing department. We do not have the
programming support to offer a lot of interactive help to these users,
and these people typically do not like to have to look through source
code to figure out how a a certain feature works.
Correspondingly, the lack of this level of documentation was certainly
one reason why Gosling's Emacs never caught on here. I have a copy of
his manual; several users even borrowed it to look at, but none began
using his Emacs as a result. When Unipress announced with great
fanfare that they were marketing Gosling's Emacs, and word got out that
they were planning to do a real manual, I sent away $30 to see what the
new version was like. I was quite surprised to find that the manual was
just a slightly updated version of the Xeroxed sheets I had, now put
into a three ring binder. In addition to finding the already noted
spelling and grammatical errors, I was struck by the incompleteness of
the manual. For example, the entire contents of section 19.2, entitled
"Electric-lisp-mode -- Assistance for Lisp programming" is the phrase
"No documentation yet".
Tom is also correct when he mentions the phenomenon whereby people tend
to stick with the editor they learn first. This is undoubtedly another
reason why we have no users of Gosling's Emacs here. But at the same
time, the fact that most users of other editors at CCA have switched to
CCA EMACS seems to indicate that this resistance can be overcome when
the difference between editors is great enough.
Of course, there are many technical reasons why people at CCA prefer CCA
EMACS to Gosling's. However, I must agree with Tom's comment that people
are more fanatical about editors than religion. (How many people here
remember the 1980 Usenix conference in Deleware where Dave Yost started
his talk on the Rand editor with the statement "Friends, be saved!")
So, I think I had better stop here before I ignite too many flames.
Steve Zimmerman
{decvax,linus}!cca!z
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1exp 10/6/83; site ihnss.UUCP
Path: utzoo!linus!security!genrad!decvax!harpo!floyd!clyde!ihnp4!ihnss!warren
From: war...@ihnss.UUCP (Warren Montgomery)
Newsgroups: net.emacs
Subject: Re: EMACS Usage
Message-ID: <1782@ihnss.UUCP>
Date: Wed, 2-Nov-83 17:30:48 EST
Article-I.D.: ihnss.1782
Posted: Wed Nov 2 17:30:48 1983
Date-Received: Sun, 6-Nov-83 07:24:17 EST
References: <6010@cca.UUCP> kobold.190 <6027@cca.UUCP>
Organization: AT&T Bell Labs, Naperville, Il
Lines: 63
I didn't see the origin of this discussion, but I have a lot of data
on editor use at BTL, collected from examining accounting files,
rather than any personal knowledge of the users. It certainly isn't
a scientific study, nor does it include data for all of the machines
at BTL. It is, however, based on the data from about 150 different
machines, and is remarkably consistent over the last year.
In general, it reveals that of the screen editor uses, vi is about
2/3, emacs (mostly mine, some Gosling's) is about 1/3, with small
amounts of others. This isn't surprising, since vi is more
generally supported and has been around longer than any of the
various flavors of emacs. Ed is invoked more commonly than
everything else put together, but I suspect that a lot of this is
due to batch usage of ed, as in shell scripts or various other tools
that do a little bit of editing as part of a larger task. The data
shows strong pockets of users of one sort of an editor or another.
Some machines show all emacs and no vi, some all vi and no emacs,
and some neither.
In selecting an editor, I agree completely with the perception that
editor preference is largly a religion once an editor is used. In
my 15 years of computing, I have used the "retype the line by
line-number" editor used in BASIC systems, an ed style editor, and
Emacs. Each transition was a bitter battle for me to accept a new
way of doing things. I was one of the last people in my group to
make the transition to Emacs, but became a true believer. My
perception is, however, that conversions are relatively rare, and in
general people stick with the editor they know and love unless you
take it away. (When I left MIT and lost access to Emacs, I
re-invented it rather than learn vi or go back to ed.)
In making the initial choice, I would think that the following
reflects what influences people most:
1) A local Guru. This is why you see pockets of use. One
organization will have an emacs Guru that shows each new
user how to set up initialization sequences and patiently
explains all of the commands to people in their
organization. Another will have a vi Guru doing the same.
2) Official Support. Some people don't like experimental
things.
3) Personal stye. My perception is that emacs/vi use may
correlate with other aspects. People who compose and edit
completely on line, without ever producing paper are more
likely to favor emacs, while those who write drafts or print
paper copy and mark it up for later editing are more likely
to favor vi. Some people are more comfortable with the
push-a-button-and-watch-what-it-does style of emacs, while
some favor a structured command oriented approach to
human-machine interaction.
I think that the quality of manuals is important in user
statisfaction, but not critical in determining how users choose
editors. Users are lazy and won't read the manual if the guy down
the hall will answer the question for them.
--
Warren Montgomery
ihnss!warren
IH x2494
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!reid@Glacier
From: reid%Glac...@sri-unix.UUCP
Newsgroups: net.emacs
Subject: Editor usage
Message-ID: <13382@sri-arpa.UUCP>
Date: Sun, 6-Nov-83 11:09:46 EST
Article-I.D.: sri-arpa.13382
Posted: Sun Nov 6 11:09:46 1983
Date-Received: Tue, 8-Nov-83 21:52:18 EST
Lines: 26
From: Brian Reid <reid@Glacier>
Here at Stanford we have about a dozen Unix VAXen, and each of them has a
"most popular" editor. If the system managers came from a VI
background, then VI is the dominant editor; if the system managers came
from a Rand background, then Rand is the dominant editor. 10 of our 12
VAXen have Gosling (of course) Emacs as the dominant editor; on most of
these systems it is rare to see, ever, a person using any other editor.
Our 1 VMS system has about 50% of the users using Emacs.
I listen with disbelief to hackers who claim that Emacs is unlearnable.
Stanford secretaries and full professors manage to learn it easily,
from the documentation and online tutorials, in a minimal amount of
time. Any editor is harder to learn if you have preconceived notions of
what editors are supposed to do, of course, and anything that you don't
want to learn will be hard to learn, so if you sit down at the Emacs
documentation prepared to find it inadequate, you will find it
inadequate.
We are all amused by CCA Emacs and by the eager attempts of its author
to use this forum to convince people that he has scientific evidence
of its superiority to Gosling's Emacs, but "nobody uses it." We're
much harder to fool out here living next to the San Andreas Fault.....
Brian Reid
Stanford
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site amd70.UUCP
Path: utzoo!linus!philabs!seismo!harpo!eagle!allegra!amd70!phil
From: p...@amd70.UUCP
Newsgroups: net.emacs
Subject: Re: Editor usage
Message-ID: <4079@amd70.UUCP>
Date: Mon, 7-Nov-83 21:45:42 EST
Article-I.D.: amd70.4079
Posted: Mon Nov 7 21:45:42 1983
Date-Received: Wed, 9-Nov-83 00:57:54 EST
References: <13382@sri-arpa.UUCP>
Organization: AMD, Santa Clara, CA
Lines: 5
Brian Reid implys that Gosling emacs is far superior to CCA's. I've
used Gosling emacs and liked it, and have never tried CCA's version.
What does Gosling emacs have that is so much better?
--
Phil Ngai (408) 988-7777 {ucbvax|decwrl|ihnp4|allegra}!amd70!phil
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!kjl@BBN-UNIX
From: kjl%BBN-U...@sri-unix.UUCP
Newsgroups: net.emacs
Subject: Re: Editor usage
Message-ID: <13485@sri-arpa.UUCP>
Date: Wed, 9-Nov-83 08:27:47 EST
Article-I.D.: sri-arpa.13485
Posted: Wed Nov 9 08:27:47 1983
Date-Received: Sun, 13-Nov-83 04:28:10 EST
Lines: 12
From: Ken J. Lebowitz <kjl@BBN-UNIX>
I have used both CCA Emacs and Goslings Emacs and I found both of
them to be useful editing tools. CCA Emacs comes chock-full of functions
which Goslings Emacs doesn't necessarily give you. With Goslings, you do
have the option of writing your own functions in Mlisp which is nice but
there are many times when it's easier to just look up the name of the
function in the manual than writing and debugging your own...
Ken Lebowitz