karl@cbrma.UUCP (Karl Kleinpaste) (09/30/86)
I am generally curious about the continued success of Unipress' and 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@bambi.UUCP (Mike Caplinger) (10/02/86)
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 mike@bellcore.com Personal opinion only. Obviously.
hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (10/02/86)
As far as we can tell, Unipress Emacs is still alive and well. There 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@ems.UUCP (Mark Colburn) (10/03/86)
In article <5205@cbrma.UUCP>, karl@cbrma.UUCP (Karl Kleinpaste) writes: > > 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
mlandau@Diamond.BBN.COM (Matt Landau) (10/04/86)
>Is anyone still shelling out real $$$ to buy either Unipress' or CCA's >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. mlandau@diamond.bbn.com 10 Moulton Street, Cambridge MA 02238 ...seismo!diamond.bbn.com!mlandau (617) 497-2429
sdl@MITRE-BEDFORD.ARPA (Litvintchouk) (10/05/86)
> 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
blm@cxsea.UUCP (10/05/86)
In article <5205@cbrma.UUCP> karl@cbrma.UUCP (Karl Kleinpaste) writes: |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
ron@brl-sem.ARPA (Ron Natalie <ron>) (10/06/86)
BRL has been using EMACS on UNIX for about 5 years now. What we started with was a copy of Montgomery's EMACS on the PDP-11's here. It worked pretty well, we proceded to pick up some of Steve Zimmerman's early modifications. As time went on, people wanted bigger and better EMACS and we did a comparison between the Zimmerman (CCA) and Gosling code and chose Goslings. We used an early release copy of it, substantially hacked by Spencer Thomas on our VAX's for several years. Last year we licensed all our machines for UNIPRESS EMACS, which is the supported outgrowth of Gosling's code. Since the furor over the proprietary nature of Montgomery's EMACS, we've it with JOVE. We have also compiled and installed GNU on our VAX. BRL has UNIX machines ranging from PDP-11's, VAX's, GOULDs, PERKIN-ELMER's, SUNs, Silicon Graphix's IRISs, Alliants, and coming later this year, CRAYs. The reason I buy UNIPRESS EMACS is that it has never taken me more than a few hours to move UNIPRESS to a new machine running UNIX, and when I have any problems there is a phone number and real people I can talk to who will help get the problem fixed. Compare this with GNU, which to start with is ihnerently non-portable code, which Stallman refuses to remove the silly VAX dependancies from. Then after I manage to cull net.emacs for the code for bug fixes, etc... it becomes a full time job to support GNU. A job which is slightly different on each machine I have. No thank you, I'll stick with UNIPRESS and let someone else do the work. UNIPRESS now offers fairly up-to-date manuals as well documenting not only the editor itself, but each piece of MLISP on the distribution (which is a lot, and yes, the manual is large). UNIPRESS is perhaps the only small company of it's kind that I've dealt with that has it's own full-time tech writer. Frequently the major trade-off between "free" software and the stuff you have to pay for is the amount of your own time you have to put in to supporting it. If you compute how much it actually takes to pay a programmer, you'll find that the $1000 or less you pay for a commercial EMACS is well worth it. For example, just doing the inital installation of GNU on our VAX took one of our programmers over a day and then I had to sit there and hack unexec for a while since we were running an early 4.3 beta at the time. Regarding performance. Yes GNU is a bear. UNIPRESS is better, but as you may have noticed by the number of number crunching machines we have that compared with most of our applications code, EMACS is small and fast. For the remaining PDP-11's and other oxygen starved life at BRL, JOVE is fast, cheap, and easy to maintain.
rbbb@RICE.EDU (David Chase) (10/07/86)
We aren't "buying" Unipress emacs, but we still use a version that we bought from them years ago. We had "maintenance" for a while, but gave up on it because (1) the upgraded version (2.00) was incompatible at the USER level with what we were accustomed to and (2) we had installed local hacks, and did not feel the urge to port them and (3) the new release was at least as buggy as what we ran at the time. Later on we had time, but it just fell through the cracks. I hear that the new releases of Unipress emacs are much more reliable, but so is the emacs that I am running right now. (For example, I compiled a version with "malloc_debug(2)" and could not knock it over). You should not underestimate the power of inertia. We are a university, and I am a graduate student, but we have a fairly huge (the entire CS department, and students in all the CS classes except "computers for poets") community of emacs users. Many of them use Mlisp packages that they do not understand. Converting most of the local code is EASY. Converting the local users is not. I am not willing to even plan the job. The investment in Mlisp code is also important (though I said conversion was relatively easy above, there is that last 1 %). Right now I am using a mailer that is pretty specific to this emacs, and I am not inclined to move to another mailer. I have tried a few, and I thought that they were awful (this includes the mailers distributed in Unipress V2.00 and gnu 17.57). Convert the code, you say? Try converting 7500 lines of Mlisp. No, it is much easier for me to sit here and write my thesis, and prepare papers for conferences. The tools I have are good enough. David (If you wonder what makes a mailer not awful, send mail and I will try to explain. It is hard, because I have come to take so much for granted. A lot of it has to do with a sensible choice of defaults.)
tp@ndmce.uucp (Terry Poot) (10/08/86)
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!tp@seismo.css.gov CSNET: ndmce!tp@smu