Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think!bbn!jr@bbn.com From: jr@bbn.com (John Robinson) Newsgroups: comp.emacs Subject: Re: Summary: Gosling/UniPress vs GNU emacs Keywords: Gosling, UniPress, GNU Message-ID: <51034@bbn.COM> Date: 17 Jan 90 16:28:56 GMT References: <113@pellan.UUCP> Sender: news@bbn.COM Reply-To: jr@bbn.com (John Robinson) Organization: BBN Systems and Technologies Corporation, Cambridge MA Lines: 68 In-reply-to: gamin@ireq-robot.UUCP (Martin Boyer) 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