gamin@ireq-robot.UUCP (Martin Boyer) (01/17/90)
I got several replies to my request for comments on the relative
merits of Unipress/Gosling and Gnu emacs. It seems that Gnu is
preferred by all those who took the time to reply. Note that this is
not necessarily a valid sample of the emacs users community; those who
take the time to read news and know how to reply to an article may not
be typical users :-).
I want to apologize for being ambiguous in my original query; I wanted
to compare UniPress, not Gosling, with GNU. I thought that Gosling
wasn't used any more, but I was wrong. There seems to be a strong
movement from Gosling to GNU, though. I suppose this will make the
review a bit more general, which is only better.
If my conclusions are wrong or if any of the authors feels that I
misquoted him (I think they were all male); please rectify the facts!
I hope this can help those that need to choose. There is some
information in etc/GOSDIFF, in the GNU emacs distribution, but this is
pretty old (from the version numbers, I would date it back to 1985).
UniPress was publishing an "Emacs Newsletter" and the 5th issue
(February 1988) addresses some of the problems of "free" software and
how they respond to it. They have valid points and if one really
wants to compare GNU and UniPress emacses, this is required reading,
but I doubt that they still have spare copies available. Further
information may be available soon, as someone
{<raney@gabor.colorado.edu> Scott Raney} posted an article last
December saying "[he's] writing a review of Unipress's Emacs". I
don't know where the review will be published and mail remained
unanswered.
The review has two parts, a presentation of those who replied, and the
replies themselves, by category. In each category, I add my own
findings and corrections when I feel I know what I'm talking about.
Everything in [square brackets] is my own editing. When ambiguous,
I'm talking about UniPress version 2.15 and GNU version 18.55. I am
aware of the fact that the latest UniPress version is 2.20, but I
don't know it inside out and I prefer not to discuss it. Last, please
apologize for the length of this posting, but a few people asked for
this to be posted and most points were valid and well written.
Martin
------------
The Players:
------------
From: John Dowding <mcgill-vision!PRC.Unisys.COM!dowding>
Organization: Unisys Corporation, Paoli Research Center; Paoli, PA
dowding> I used Unipress Emacs for 4 years, and have recently (within 2
dowding> years) switched to Gnuemacs.
From: Vick Khera <mcgill-vision!cs.duke.edu!khera>
[Department of Computer Science, Duke University, Durham, NC 27706]
khera> When I was at the U of Maryland, I used Gosling/UniPress emacs
khera> (gosmacs) exclusively. It is quick and small and worked well with
khera> SunView. Now at Duke, I use GNU emacs (gnumacs) exclusively since we
khera> don't have gosmacs
Date: Fri, 12 Jan 90 07:11:59 EST
From: [montanaro@crdgw1.ge.com] (Skip Montanaro)
montanaro> I wrote the original [Gosling emulation in GNU Emacs]
montanaro> several years ago.
From: John Robinson <jr@bbn.com>
Organization: BBN Systems and Technologies Corporation, Cambridge MA
jr> I have some experience with Gosling emacs from way back in the
jr> pre-Unipress days, so that may qualify me. I know quite a bit
jr> about GNU emacs.
From: mcgill-vision!uunet!world.std.com!spike (Joe Ilacqua)
Organization: Software Tool & Die
spike> I have installed and used GNU Emacs under [lots of
spike> environments].
From: Nick Radcliffe <mcgill-vision!uunet!castle.ed.ac.uk!njr>
Institution: ICE AGE
njr> I have made the switch from Gosling to GNU recently and have found
njr> it a mixed blessing. I moved for two reasons:
njr>
njr> 1. I am strongly committed to free software [...]
njr>
njr> 2. It was getting ever harder to persuade the powers that be that
njr> Gosling was worth paying for (just for me...)
From: mcgill-vision!uunet!pedz.austin.ibm.com!pedz (Perry Smith x3-4076)
pedz> I classify myself as an ex Gosling emacs user (not novice nor
pedz> guru) and a current GNU user. I was the system manager at a site
pedz> with Goslings but I only wrote lisp code for it. I have written
pedz> both C code and lisp code for GNU. [...] I've never used emacs on
pedz> a sun though. I do use it inside of X on an RT and I've used it
pedz> on ascii terminals from a Vax and a few 68020 machines.
From: [dwells@nrao.edu] (Don Wells)
Organization: National Radio Astronomy Observatory, Charlottesville, VA
dwells> I have an original Gosling Unix kit from before Unipress.
dwells> Also, before Unipress I used the VMS version obtained [...]
dwells> while the Unipress people apparently were at DEC. I used
dwells> Unipress for about 5 years (83? -- 88), on VMS, SunOS and
dwells> ConvexOS. I wrote plenty of mlisp, but mostly not very clever
dwells> things.
From: amoss@batata.Huji.AC.IL (amos shapira)
amoss>
From: [rae%alias@csri.toronto.edu] (Reid Ellis)
rae> I used Unipress Emacs on Iris 4D workstations for about 9 months.
rae> Then I switched over to GNU Emacs.
From: Martin Boyer <mboyer@ireq-robot.uucp>
[Laboratoire de robotique, Institut de recherche d'Hydro-Quebec]
mboyer> I am using an "improved" version 2.15 (I also have 2.20, but I
mboyer> don't use it). I know UniPress emacs very well (down to the
mboyer> source code). I maintain local additions and I consider myself
mboyer> to be a UniPress emacs guru (whether or not I really am seems
mboyer> irrelevant :-))
[Note: That's me, and I will get the last word! -- Martin]
---------------------------------------------------------------------------
------------
The Replies:
------------
Foreign language support (8-bit characters mainly):
---------------------------------------------------
khera> I believe under X [with GNU] you can define your own display
khera> characters for certain codes. Don't quote me on this [...]
[sorry, I just did! -- Martin]
jr> not yet in the [GNU] distribution, but both Eurpoeans and Japanese
jr> have worked on this. There is a Japanese GNU emacs available
jr> called nemace, with its own distribution point and newsgroup. [I
jr> think version 19 will include] the 8-bit character support
pedz> There were recent patches for 8 bit support [in GNU]. I've not
pedz> tried them out but I figure they work.
mboyer> Ok, GNU doesn't have it yet. UniPress does support 8-bit under
mboyer> SunWindows and seems to support Kanji. I probably supports
mboyer> 8-bit on other terminals that allow 256 characters in a font
mboyer> (on a Sun, you have to wait for 8-bit ttys, I believe they are
mboyer> supported in SunOS 4.0).
Speed:
------
khera> once [GNU] is fired up, it is quite reasonable (at least on a sun
khera> 3/60 and up and on all the sun 4 line).
jr> [GNU is] fine for me on a vanilla sun 3/50M 4 meg under X11R4.
jr> Also from home at 2400 baud dialup.
njr> The speed of [GNU's] screen is incredibly impressive. On a
njr> dial-up at 300 baud, it beats VI so bad its not even funny. As
njr> far as speed of the code, I've used it on a Vax 11/750 and that
njr> was not enough horse-power to make me comfortable. The help and
njr> spell checker, etc becomes too painful to be useful. On a 68020,
njr> its very nice though. [...] In all cases though, I've been one of
njr> the few using emacs on the system. Usually other people are
njr> running vi so I can't say what it does to a 68020 when 5 or 10
njr> people use it at the same time.
njr>
njr> I have heard lots of stories about Gosling spending ages tweaking
njr> [terminal updating], but I have never noticed the difference
rae> GNU is a bit slower to start, but it runs much faster.
mboyer> UniPress is also very fast, specially under its own SunView
mboyer> driver. I compared the UniPress termcap driver with GNU (which
mboyer> *should* be the same because they work with the same
mboyer> information) and, at 1200 baud on a vt100 clone, GNU easily
mboyer> beats UniPress. Granted, UniPress recommends using their vt100
mboyer> driver, but then I can't reprogram the function keys and I have
mboyer> to compile the driver in the emacs binary. The garbage
mboyer> collector (which doesn't exist in UniPress) is a *real* pain
mboyer> and really slows GNU down. Fortunately, I found how to reduce
mboyer> garbage collection frequency.
Terminal support:
-----------------
dowding> [Gnuemacs] works better with X windows (I couldn't get
dowding> unipress emacs to run on a different workstation than the one
dowding> I was logged in on).
khera> [Gnu emacs] works with curses. any terminal your machine knows
khera> about, it will work with. but it does need full screen.
khera> [Gnu] emacs works best under X. then you have full mouse
khera> control, etc. otherwise, no fancy things that i can recall.
jr> I guess you are presuming a window system here. All those things
jr> are there for X [in GNU]. Stallman's attitude probably wouldn't
jr> suffer too much sunwindows stuff going in, though he'll distribute
jr> it if someone else provides it, but won't maintain it at FSF. I
jr> think the sunview support may include all you list except menus.
jr> With XView, emacs will be content to run as an X client. FSF
jr> includes the X distribution on their tapes. The X menus
jr> implementation uses obslete X stuff, but it is provided with the
jr> source as a library in case your X is too recent. It requires
jr> `xset bc' (bug compatibility mode) with X11R4. version 19 [...]
jr> will include multiple-window support under X
pedz> The mouse in X is supported and is brought out to the lisp code
pedz> so you can do anything that you want to. The current
pedz> implementation does not take advantage of this really. The rest
pedz> of it is there if you pick things up off of the net or write them
pedz> yourself. For example, the X11 keyboard is sorta kludgy. [...]
pedz> fonts and color and reverse video are the same. I just saw
pedz> something to do bold and underlines. Its coming but is basically
pedz> a little imature at this point.
rae> Under X you can also set the fonts and colours.
rae> Unipress has its own window under the Iris' windowing system, GNU
rae> Emacs doesn't. However, GNU Emacs has its own window under X
rae> whereas Unipress doesn't -- and we seem to be moving to X around
rae> here, so.. :)
mboyer> rae is right. UniPress provides fine window support, but with
mboyer> one specialized *driver* per window system. With GNU, it seems
mboyer> easier to add window support by creating one *front-end* per
mboyer> window system. At least, the problem is cut in smaller pieces.
mboyer> This is at the expense of functionality; the SunView driver in
mboyer> UniPress is doing things that GNU's emacstool can't dream of,
mboyer> the result is a "smoother" feel for UniPress under SunView.
mboyer> (Bear in mind that I have seriously hacked through what
mboyer> UniPress provided). Finally, GNU does support menus under
mboyer> sunview.
Typeout/transient/temporary/pop-up windows:
-------------------------------------------
jr> *Help* buffer is persistent. Some packages flush their private
jr> windows when they're done, some don't. The minibuffer (echo line)
jr> is a real buffer, but not quite. Removing the *Help* buffer is
jr> easy, and help functions echo a brief line in the minibuffer to say
jr> how to do it (either ^X 1 or ^X 4 b RET).
pedz> I can't recall Goslings help windows, etc. I do remember the
pedz> feeling when I first moved to GNU that GNU's were not as good --
pedz> actually they have a different philosophy. I believe that all of
pedz> this is in lisp though and so should be easy to modify. For
pedz> example the single line window at the bottom of the screen was
pedz> modified to grow and shrink by someone on the net recently.
rae> Control of [GNU] buffers seems more powerful to me, but I'm a
rae> user, not a lisp hacker.
mboyer> jr is right; GNU doesn't appear to have transient windows and
mboyer> packages are responsible for flushing their private windows
mboyer> when they're done. ^X 1 is not always what I want and ^X 4 b
mboyer> RET never seems to do what I want. Transient/typeout windows
mboyer> is a concept that I dearly miss in GNU.
Maintainability:
----------------
dowding> Unipress emacs comes with "support".
jr> Emacs lisp is a far superior variety to Gosling's, IMHO. It is a
jr> lot closer to Common Lisp. The ways it has for doing things like
jr> handling interactive functions, buffer variables, hooks for
jr> customizations at most important places, major and minor modes are
jr> mostly pretty good.
pedz> The lisp code in GNU is like a breath of fresh air -- almost a
pedz> religious experience compared to mock-lisp. I hated mock-lisp
pedz> and that was before I know anything about lisp. Now that I have
pedz> seen what lisp is suppose to be, its very nice. The C code is
pedz> really beautifull. Really nicely formatted and consistant. The
pedz> one exception is sysdep.c which is where everyone else plugs in
pedz> their system dependencies. This is a huge kludge but thats not
pedz> Stallman's fault. I've only poked around a little but I find it
pedz> very nice. Also, you have ton's of help from the net so I would
pedz> say that the maintenance is excellent.
mboyer> Maintainability is the primary reason why I wanted to switch,
mboyer> so... Even though GNU is written by several "independent"
mboyer> people, it seems surprisingly consistent.
Ease of use:
------------
dowding> Unipress emacs has a feature I loved, clicking on a mode line
dowding> and dragging it to increase/decrease buffer sizes.
dowding> I didn't find switching to Gnuemacs much more difficult than
dowding> switching from one Unipress version to another.
khera> [Gnu is] just as easy as gosmacs. it has a tutorial and even
khera> better is the INFO mode.
jr> [For Gnu it] seems to vary with the user. Some like the tutorial
jr> and come up fast, other flounder a lot before they get comfortable
jr> (this I think happens to people coming from some other universe,
jr> such as EDT, or vi, or wordstar) There are emulations for a lot of
jr> other editors, including the ones I listed above. I don't think
jr> the transition from Gosling should be that hard, but others I know
jr> are resistant to doing it so... As you know there is a Gosling
jr> emulation mode too.
njr> In many cases GNU has features that are useful and which Gosling
njr> doesn't have---for example, file name completion, vertically split
njr> windows, full lisp sitting under it and correspondingly better
njr> cusomisability, undo features etc.
njr> But Gosling, it seems to me, thought more carefully about the
njr> kinds of operations that are useful in editors and built an editor
njr> which, in my view, makes *editing* faster and easier than any
njr> other I know. More than this, he doesn't try to `hold my hand' by
njr> asking me to confirm things all the time: if I tell Gosling emacs
njr> to do something, it does it, and if I screwed up that's *my*
njr> problem. It's a matter of taste, but this suits me fine, and I'm
njr> sure reduces the number of actual mistakes I make and time I lose.
njr>
njr> There are lots of cases where Gosling, I think, appreciated that
njr> the bulk of mistakes are noticed and need correcting *immediately*
njr> after they are made.
njr>
njr> Thus, for example:
njr>
njr> ^T transposing the *previous two* characters (in my view,
njr> just about the best feature of Gosling Emacs)
njr>
njr> Case changing commands: these should affect the
njr> *current or previous* word.
njr>
njr> I have spent ages building quiet versions of commands---that don't
njr> ask you to confirm things---and some time deleting infuriating
njr> features like interpreting ^N to mean `insert a blank line' if you
njr> are at the end of the buffer.
pedz> I don't know from who's perspective. If you have novice user's
pedz> that you are supporting, then I would say its a toss up. If you
pedz> are writing lisp code, I find [GNU] infinately easier. If you
pedz> are talking about mail handling, news handling, etc., GNU was
pedz> weaker when it first came out but at this point, every concept
pedz> under the sun has been thrown into it. There is mail and mh
pedz> support, two ways to read news, support for every language I can
pedz> think of, and the list continues.
dwells> I used Unipress for about 5 years (83? -- 88) [...] after the
dwells> switch I had some finger retraining to do, but now about 16
dwells> months later I judge that GNU is marginally better
amoss> I first didn't like GNU emacs just because I was used to
amoss> gosling, with all it's quircks (sp?), but now I'm just dieing
amoss> [...] to install GNU Emacs on my main machine.
rae> Hey, it's EMACS. If you want easy-to-use, go use MacWrite. :)
rae> It's asily on par with Unipress, if that's what you mean. They're
rae> very very similar programs after all.
mboyer> UniPress does have file name completion. And, to answer
mboyer> dowding's problem, I have functions to move the mode line with
mboyer> the mouse under GNU/SunView. As for the "features", this is
mboyer> just a gut feeling after using GNU for a little over a month,
mboyer> but GNU seems to use more "magic" but it generally does the
mboyer> right thing; the default for most queries is generally what I
mboyer> want, but some "automatic" features are, as njr pointed out,
mboyer> "infuriating".
Consistency across machines, operating systems, and terminals:
--------------------------------------------------------------
khera> [GNU] works the same on every machine i've tried. sun3's,
khera> vaxen, sun4's butterfly GP-1000 even.
spike> I have installed and used GNU Emacs under SYSV, BSD and hybrids
spike> of the two UNIXs, on SUNs, VAXen, SGIs, 386s, Encores, and AT&T
spike> 3Bs. The only differences are minor operating systems things,
spike> i.e. SYSV does not have job control so Emacs runs a sub shell
spike> instead.
spike>
spike> I have used Gnu Emacs on a number of ANSI and non-ANSI terminals
spike> without any problems or noticeable differences.
pedz> [GNU] emacs provides a much more consistant user interface than
pedz> Unix itself does. It provides pseudo select, pseudo job control
pedz> etc, etc. It even provides a consistant interface when running
pedz> on VMS.
rae> EMACS has this all over Unipress. You have the source. You
rae> compile it everywhere. It runs the same. With Unipress you have
rae> to wait until *they* finish porting to your platform.
mboyer> You can also have the source with UniPress (it is not very
mboyer> expensive) and recompiling is no big deal. Installing UniPress
mboyer> is more difficult (if you want to customize it) than installing
mboyer> GNU. From the installation scripts, UniPress seems to compile
mboyer> and run on just about anything. As I mentioned before, UniPress
mboyer> handles special terminals by customized drivers and, therefore,
mboyer> differences may arise. UniPress also provides sub-shells when
mboyer> there is no job control available.
Documentation:
--------------
khera> [GNU's documentation is] quite useful as a reference, not so
khera> great to learn from. but then i did not learn emacs from
khera> gnumacs...
jr> I think the GNU Users' Manual is pretty good, and the whole thing
jr> is available online with the distirbution in the Info facility.
jr> Others want to see the Emacs-lisp programmers manual before the
jr> edit the first file. The latter is nearing completion, and can be
jr> gotten in a usable form over the net today.
spike> The online help is complete. The online beginner tutorial is
spike> good. It is a little hard to pick up some of the more advanced
spike> features unless you know they are there.
pedz> [GNU is] better than Goslings I feel sure. [The internal
pedz> documentation if very nice.] There is a short paragraph on each
pedz> function which is placed directly in the C or lisp code and
pedz> available via help. There is also the user's manual that can be
pedz> printed out or viewed from info. Aside from that there is the
pedz> lisp reference manual which also can be printed or viewed from
pedz> info.
rae> Unipress' is more glossy and polished, but GNU's seems more useful
rae> and complete.
mboyer> UniPress also has a decent info mode and the online help is
mboyer> *much* faster under UniPress than under GNU. With GNU, I
mboyer> really fear that my next apropos is going to take 5 minutes.
mboyer> With UniPress, worst case is a matter of seconds. The bad side
mboyer> is that there is no 'documentation' slot in the UniPress
mboyer> objects; you have to index by name in some database.
[Note: The following were not specifically requested, but these are
valid points nevertheless. -- Martin]
Use of system resources:
------------------------
dowding> I believe (I am no Unix Guru) that Unipress makes better use
dowding> of memory by sharing the code segments across multiple emacs
dowding> sessions running on the same machine. Each Gnuemacs session
dowding> takes at least 2M, and only gets larger.
khera> I use another emacs called JOVE for quick edits and mail
khera> messages. JOVE starts up quite quickly. Gosmacs is pretty fast
khera> too, but gnumacs can take quite some time. Also, gnumacs is a
khera> real memory hog (but then so are the others I suppose...)
mboyer> UniPress' use of system resources was never a problem for me.
Stability:
----------
khera> Gnumacs seems fairly stable and I seriously doubt that anybody
khera> is going to make a radical change to it's functionality.
mboyer> Stability is another reason why I wanted to switch, so ...
Emulation:
----------
montanaro> I believe later versions [of GNU] have added some emulation
montanaro> functions as well.
jr> There is a lot of compatibility [in GNU], and I think a mlisp
jr> translator. But you still have to fix up some rough edges
jr> yourself. Think of it as an elisp learning exercise. Once you get
jr> your package ported, you'll know enough to rewrite it "right".
amoss> there is a gosling-emacs emulation mode in GNU emacs, run
amoss> set-gosmacs-bindings, you better convince [users] to try this,
amoss> it will save a lot of trouble maintaining gosling emacs, which I
amoss> consider as obsolate (although I'm using it right now to write
amoss> this message :-).
amoss> in the GNU emacs distribution directory there should be a file
amoss> called [etc/GOSDIFF] which describes the differences between
amoss> [Gosling and GNU emacses].
rae> After a little lisp hacking [lisp is not one of My Languages :)] I
rae> managed to emulate all of the Unipress features I needed [I didn't
rae> like the gosmacs-mode] except for one [the previous regexp is
rae> *NOT* the default for re-search-forward].
mboyer> UniPress also has GNU, Zmacs, EDT, vi, etc. emulation modes. I
mboyer> never tried any of them though.
Miscellaneous:
--------------
dowding> Unipress emacs is used in the Quintus Prolog development
dowding> environment.
khera> whichever program you use, you will have to follow what the
khera> author's idea of emacs should be.
montanaro> GNU Emacs has been customized by lots of people over the
montanaro> same four years you've spent on Gosling's Emacs. Quite
montanaro> possibly, you'll find stuff that's similar to your
montanaro> customizations, and you'll definitely find lots of
montanaro> interesting new stuff.
njr> I am strongly committed to free software and therefore feel I
njr> should support GNU over Gosling (or rather, over Unipress,
njr> which is what I used to use).
dwells> I switched in 88 because I judged from anectdotal evidence that
dwells> they were roughly equal in 88, and GNU is free, which was
dwells> important to us.
mboyer> UniPress was at some point in time part of the ART (by
mboyer> Inference) programming environment, there was also some support
mboyer> for Sun Common LISP but all that was dropped. I heard about
mboyer> two reasons, one is that UniPress was asking for licensing fees
mboyer> (not verified) and the other is that GNU is much better for
mboyer> customization.
In the past, I have found that UniPress was always first in
incorporating features and porting to new environments. This is why I
chose it back in '85. Release 2.20 seems to provide very neat
features and a very good interface with NeWS and X windows. The
SunView support has dropped a little, unfortunately, and I can't live
with it. A few other things were broken between 2.15 and 2.20 and I
can't live with that either. My greatest fear was that I would have
problems switching from UniPress to GNU, but it is not dramatic so
far. I still have to port my packages and extensions from UniPress,
but given that elisp is more flexible than mlisp, it should not be
impossible. From this point, I can draw my own conclusions. Many
thanks to those who took the time to respond.
--
Martin Boyer ireq-robot!mboyer@Larry.McRCIM.McGILL.EDU
Institut de recherche d'Hydro-Quebec mboyer@ireq-robot.uucp
Varennes, QC, Canada J3X 1S1
+1 514 652-8136jr@bbn.com (John Robinson) (01/18/90)
Clearing up a bit, and commenting on Martin's nice summary... In article <113@pellan.UUCP>, gamin@ireq-robot (Martin Boyer) writes: >jr> There is a Japanese GNU emacs available >jr> called nemace, with its own distribution point and newsgroup. Oops - make that nemacs, or perhaps NEMACS. And I guess it has a mailing list, not a newsgroup. >mboyer> jr is right; GNU doesn't appear to have transient windows and >mboyer> packages are responsible for flushing their private windows >mboyer> when they're done. ^X 1 is not always what I want and ^X 4 b >mboyer> RET never seems to do what I want. Transient/typeout windows >mboyer> is a concept that I dearly miss in GNU. There are some cases that are transient. One I use all the time (to explore directory trees, mainly) is the completions for things you are typing into the minibuffer for interactive commands. Once you complete or abort the command that is prompting, the completions window disappears... >dowding> I believe (I am no Unix Guru) that Unipress makes better use >dowding> of memory by sharing the code segments across multiple emacs >dowding> sessions running on the same machine. Each Gnuemacs session >dowding> takes at least 2M, and only gets larger. On machine that permit it, GNU emacs shares code segments. A lot of its functionality may be in lisp libraries, however. It has a mechanism for getting these shared. It's in the make files; there is a (machine-dependent) feature called undump which takes a running emacs and moves the loaded elisp into the code segment, thus making it shareable. If you and your users commonly load a lisp package, you should arrange to put it into the shareable image (we do this for mh-e, for example). This also keeps it out of the allocator's and garbage collector's way. Documentation strings for pre-loaded stuff are saved off in a separate file to avoid taking core space. I've considered trying to build a emacs that has every file pre-loaded that I ever use (:-). Non-pre-loaded emacses have to read the elisp files that are normally preloaded when you start it. This is quite slow. There are workarounds, however. The emacs server package in the distribution allows other processes to invoke a running emacs through emacsclient, which sends it instructions over a port or pipe to open a buffer on some file. Probably requires either a window system or shell job control or emacs shell mode (or two terminals :-). I don't believe GNU emacs can live with dynamic libraries (SunOS4) yet. I don't get nearly as big core images as 2M. Right now, my 18.55 executable is: -rwxr-xr-x 1 jr 1507328 Sep 20 16:19 /usr/local/bin/emacs* (not stripped). The core image is 558+254; resident 34+26 (1K blocks). After loading several packages, including gnews which is quite large. Performance for me got a lot better when I switched from X11R3 to X11R4. This is due to a much better Xsun: it updates the screen very fast (beats Sunview, I'd say), and it does not leak memory like the R3 server. Xview looks like it'll be the last nail in the Sunview coffin... -- /jr, nee John Robinson Life did not take over the globe by combat, jr@bbn.com or bbn!jr but by networking -- Lynn Margulis
raney@boulder.Colorado.EDU (Scott Raney) (01/19/90)
The review of Unipress Emacs that I have been working on for
Unix World magazine is about done. I'm not sure what month
it will be published, but it should be within a couple (March?
April?). Apologies to those who sent me info that I didn't
thank personally, please consider this a thank you note.
In my comparison of GNU with Unipress Emacs there were two
points that were especially noteworthy. The first is the
relative stability of the editors. GNU is rock-solid, whereas
Unipress (at least version 2.2 on HP 9000/300's) is really
buggy. Even after I got an updated version from Unipress
(corrupted files on their distribution system), there were
numerous bugs, especially in the X interface. I think this
is unacceptable in a commercial product.
The second is the level of support. I'd trade Unipress's
whole tech-support department for one GNU guru with a little
free time. The level of support and communication available
from the news groups and email to other GNU Emacs users is
far superior to that available from any commercial software
company that I have had experience with.
As a software consultant, I feel somewhat somewhat threatened
by the idea that free software can really work. But as the FSF
and the members of the GNU community have shown, it clearly can.
Scott Raney
======================================================================
Scott Raney No other person or organization
raney@gabor.colorado.edu can be held responsible for my
(303)492-7709 or (303)499-9855 opinions or actions