Question of curiosity: who is still buying Unipress or CCA?
Karl Kleinpaste
CCA's emacses in the face of GNU Emacs' close-to-universal availability
combined with the fact that it runs on most common machines out there
today, even such beasts as the 3Bs, diffs for which were posted here
just a couple of days ago. Especially in light of having made it (so
I understand) into the 4.3BSD release tapes, I wonder:
Is anyone still shelling out real $$$ to buy either Unipress' or CCA's
emacs programs? If so, why? Offhand, I can think of only 2 reasons
why I would do so myself: [1] If I were using a machine with a small
address space incapable of coping with the huge amount of storage
required by GNU Emacs, then I'd want someone else's. [2] If I wanted
a blindingly fast emacs, then I'd drop GNU Emacs, but I'd pick up
microEmacs or somesuch thing, not getting Unipress or CCA even then.
Any devoted Unipress or CCA users out there? Or even Montgomery's?
Care to comment?
--
Karl Kleinpaste
Mike Caplinger
Let's face it, some of us just don't have the time to learn a new and
at least slightly different Emacs variant. I still use Gosling's and
probably will for the forseeable future, just because I have a big
investment in knowing how to use it, and a big pile of MLisp code
(and don't tell me about automatic conversion!)
Also, in all fairness tracking the various releases of GNU would seem
to be a full-time job, and we don't have the time to do it. Most people
around here still use Montgomery's Emacs for the same reason I use
Gosling's -- they're used to it.
Unipress Emacs is pretty cheap, and money is hardly a big issue in some
companies. Besides, it's supported, kind of. (Actually I can't make
any comments about what support is like these days. In the past it wasn't
too great.)
You can only imagine that some companies wouldn't be too thrilled with
the "GNU Manifesto". In fact, I've never checked, but it would be
a not totally unreasonable response if our lawyers refused to let
us use GNU for that reason.
Mike Caplinger
mi...@bellcore.com
Personal opinion only.
Obviously.
Charles Hedrick
are a number of direct customers and also vendors who redistribute it.
There are plenty of reasons why a customer may want a company that it
can hold responsible for support. Also, they have been doing some
cute things to Emacs recently. I have talked to people at Unipress
about this issue. They don't see Gnu as a threat. They believe, as I
do, that there is room for both public domain and commerical versions
of Emacs. We use both, though Gnu tends to predominate.
Mark Colburn
>
> Is anyone still shelling out real $$$ to buy either Unipress' or CCA's
> emacs programs?
We are currently running a copy of Unipress Emacs. I think that the main
reason that we were willing to shell out $1,000 for Emacs was due to the
fact that we were not connected to Usenet at the time that we purchased it
and so we were not aware that a portable public domain version existed; also
the amount of time that was spent to get the system up was minimal.
Unipress was very helpful in helping us get the system up and running on our
Arete 1200. Also, we can get upgrades and documentation from Unipress for
little to no cost and be sure that they will work on our machine with very
little effort on our part.
This is not a plug for Unipress Emacs, merely some reasons why people might
be willing to shell out real dollars to get a package such as Emacs that is
also in the public domain. I think that if I had known about GNU Emacs prior
to the purchase of Unipress, we would have gotten GNU Emacs. Oh, well.
I would still be interesting in getting a copy of GNU Emacs and comparing it
to Unipress Emacs and seeing what the differences are. When I do, I will
post the results to the net if there is an interest for this information.
--
Mark H. Colburn UUCP: ihnp4!rosevax!ems!mark
EMS/McGraw-Hill ATT: (612) 829-8200
9855 West 78th Street
Eden Prairie, MN 55344
pre...@ccvaxa.uucp
> Is anyone still shelling out real $$$ to buy either Unipress' or CCA's
> emacs programs? If so, why?
There are several reasons for going with the commercial versions:
Support (not every site has hordes of hackers free to hunt for
problems and answer questions), features (there are still
some things that they can do that GNU can't -- like pop-up
windows), and libraries (some of the GNU packages are not as
capable as the corresponding Gosling packages -- mail and
c-mode come to mind). Support is by far the most powerful
of those, especially to non-techie sites; the commercial
Emacses have phone numbers you can call for help.
Having said which, let me add that most Emacs users here have
switched to GNU for most purposes (I still read mail in Gosling
and I still do new code creation in Gosling).
--
scott preece
gould/csd - urbana
uucp: ihnp4!uiucdcs!ccvaxa!preece
arpa: preece@gswd-vms
Matt Landau
>emacs programs? If so, why?
We're still "shelling out real $$$" for Unipress Emacs (v2.10), and quite
happy with it. Why Unipress instead of Gnu? Support, for one thing.
Unipress is very good about bug fixes, enhancements, etc. I find that
Unipress Emacs is more solid and better documented than Gnu (the brand new
version 2.10 documetation is absolutely wonderful!), and if I find problems,
I call or mail to Unipress and the problems get fixed - I don't have the time
to hack around with Gnu sources, even if I wanted to.
Unipress also seems to be one or two steps ahead of Gnu when it comes to
features like process control. Recent versions of Unipress allow you to do
things like run background processes and specify arbitrary pieces of MLisp
code to be called whenever the process changes state. I use this facility to
compile programs and -- when the compilation is finished -- scan the error log
buffer for certain "standard" error messages, fix the code involved, and
restart the compilation. All while I work on other things.
Finally, Unipress has some interesting ideas for future versions of Emacs and
related tools. These include CEmacs (a complete C development environment
built on top of Emacs, with simple user interfaces for naive Emacs users),
a multi-window/multi-buffer VI that I assume will be built on top of the
Emacs diaply and buffer management kernel, and alternate extension languages
for Emacs. (Personally, I'd like to see a C-like extension language, a la
Epsilon.)
I think the inclusion of Gnu Emacs on the 4.3 tape will be a good thing all
around. From what I hear, Gnu is great if (1) you don't want to spend money
on an Emacs, (2) you have time to hack on the sources if necessary, and (3)
you don't need the more sophisticated features of some other Emacs'es. The
fact that Gnu is free and widely available should provide incentive for the
commerical Emacs suppliers to go for product differentiation by making their
versions better, stronger, faster, more flexible, etc. Everyone wins
(assuming that Gnu doesn't drive the others out of business, which certainly
doesn't appear to be the case).
--
Matt Landau BBN Laboratories, Inc.
mla...@diamond.bbn.com 10 Moulton Street, Cambridge MA 02238
...seismo!diamond.bbn.com!mlandau (617) 497-2429
Litvintchouk
> Unipress also seems to be one or two steps ahead of Gnu when it comes to
> features like process control. Recent versions of Unipress allow you to do
> things like run background processes and specify arbitrary pieces of MLisp
> code to be called whenever the process changes state. I use this facility to
> compile programs and -- when the compilation is finished -- scan the error log
> buffer for certain "standard" error messages, fix the code involved, and
> restart the compilation. All while I work on other things.
GNU Emacs has all these features too. Examples (taken from the "help"
documentation):
set-process-sentinel:
Give PROCESS the sentinel SENTINEL; nil for none.
The sentinel is called as a function when the process changes state.
set-process-filter:
Give PROCESS the filter function FILTER; nil means no filter.
When a process has a filter, each time it does output
the entire string of output is passed to the filter.
compile:
Compile the program including the current buffer. Default: run `make'.
Runs COMMAND, a shell command, in a separate process asynchronously
with output going to the buffer *compilation*.
You can then use the command C-x ` to find the next error message
and move to the source code that caused it.
Even more importantly, processes, windows and buffers are all treated
as "first-class citizens" in GNU Emacs. Thus, you can create complex
data structures containing processes, windows and/or buffers as atomic
objects. This feature has tremendous potential for programming new
applications.
Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA 01730
(617)271-7753
ARPA: sdl@mitre-bedford
UUCP: ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdl
b...@cxsea.uucp
|Is anyone still shelling out real $$$ to buy either Unipress' or CCA's
|emacs programs? If so, why? Offhand, I can think of only 2 reasons
|why I would do so myself: [1] If I were using a machine with a small
|address space incapable of coping with the huge amount of storage
|required by GNU Emacs, then I'd want someone else's. [2] If I wanted
|a blindingly fast emacs, then I'd drop GNU Emacs, but I'd pick up
|microEmacs or somesuch thing, not getting Unipress or CCA even then.
Yes, we're still using Unipress Emacs, for a number of reasons (in no
particular order):
1. GNU Emacs is HUGE. We're running on small machines with relatively slow
disks and small amounts of memory. Even Unipress Emacs is getting a little
large.
2. We're running on System V, so no paging (until Release 3, I guess).
3. Unipress supports asynchronous processes on System V. I have no idea if
GNU does or not, but I know Unipress does.
4. Unipress is well supported. There's someone I can call, or send mail to,
who is running the same version Emacs I'm running, and can reproduce my
problems. I don't have time to do a lot of my own support. As far as I know,
there's no one who's sole job is to support GNU on System V.
5. Inertia. Unipress is the Emacs I've used since I started using Unix, so
the key bindings have always been pretty much the same, and mlisp is still
the same (of course new functions are being added all the time, but the old
functions that I know still work.)
6. Stability. This isn't true so much any more, but when GNU Emacs was first
available, it seemed every week there were 500K of diffs for the next
version. I don't have access to Arpanet, and purchasing a new tape every
time a new version became available would have been quite expensive.
7. Unipress Emacs isn't really very expensive.
I'll admit none of them are real overriding reasons not to switch (except
number 3, if GNU doesn't support asynchronous processes on System V. I've
got to have my shell window!), but I haven't seen any real overriding reason
to switch either. If I was on a VAX running 4.n, then I'd probably use GNU,
but I'm not (not that I don't dream about it :-)).
--
Brian L. Matthews
Computer X Inc. - a division of Motorola New Enterprises
..{utcsri!utzoo!mnetor, uw-beaver!ssc-vax}!cxsea!blm
+1 206 251 6811
Terry Poot
We bought Unipress emacs before we were on the net, so we had not
heard of Gnu emacs. However, if I had to do it again, I'm not sure
what I'd buy. Unipress emacs only works marginally on our machine,
and Unipress is not interested in fixing it. On the other hand, Gnu
doesn't work on our machine at all (Masscomp). I haven't looked into
CCA, but after having been burned by Unipress (they CLAIM to work on
this machine), I don't know if I'd trust them anyway.
Unipress emacs does work on this machine, to a large degree (I'm
using it now), but most of the packages won't, primarily because
filter-region is broken. Thus if you use C mode and hit ESC-j to
format your file, it deletes all of your text. Some of the helper
utilities are broken as well (like collectmail, making rmail
useless). Emacs promised me a fixed version within 2 weeks when I
told them of these things (~June, 1985). Needless to say, it never
arrived. We are a binary licensee, so I can't fix it.
Rumor has it that a Masscomp port of GNU exists, so it is probably
just a matter of time before it is merged in. Until then, we limp
along with Unipress. I'm not sure I'd ever do business with them
again.
(The above is not an attack just to be nasty. There has been a lot
of praise for Unipress here lately, and they probably deserve it.
This account may present a more complete picture to those who might
be influenced in their choice of products by this discussion. Any
vendor will have a certain number of dissatisfied customers. For
what it is worth, I'm the only one I know about for Unipress emacs.
Sometimes the business interests of a company are better served by
hanging a few customers out to dry, so as to provide better service
to the rest. It doesn't help me any, but you might not have these
problems with them.)
--
Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741
8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA
UUCP: {seismo!c1east | cbosgd!sun | allegra}!convex!ndmce!tp
INTERNET: ndmce!t...@seismo.css.gov CSNET: ndmce!tp@smu
Paul Rubin
rates and phone numbers are in the file etc/SERVICE, included in the
distribution. This is not the same as having a central corporation standing
by to answer your questions, but (for a fee) they are probably willing to do
more work for you (such as writing custom macros, porting Emacs to your
machine, or coming to your site to teach users) and might be nearer you
(until the commercial suppliers open offices in places like Italy and
Australia). Most importantly, you pay for the service only if you need it.
Paul Rubin
GNU collaborator (sometimes)
Mike Meyer
>features (there are still
>some things that they can do that GNU can't -- like pop-up
>windows)
GNU does do pop-up windows. At least the version I have (17.63 or so)
does.
On the other hand, I've never seen a version of Goslings where you
could turn pop-up windows off and have things work right. To many
packages assumed that change-to-buffer (may have the wrong name here)
did a GNU-like "pop-to-buffer." This annoys me no end...
<mike