Xref: utzoo comp.misc:5697 comp.editors:607 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!ncar!boulder!sunybcs!rutgers!aramis.rutgers.edu!athos.rutgers.edu!gaynor From: gaynor@athos.rutgers.edu (Silver) Newsgroups: comp.misc,comp.editors Subject: Re: UNIX needs a real text editor Message-ID: Date: 2 Apr 89 09:28:09 GMT References: <4392@enea.se> <248@usl-pc.usl.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 63 >>> = gregg@ihlpb.att.com >> = sommar@enea.se (??) > = jpdres10@usl-pc.usl.edu >>> [Lisp is too slow for an extension language.] Not at all, if it's compiled. Now, the target machine for the code is the issue. GNU Emacs interprets its own compiled code in software, so, although it's _much_ faster than interpreting straight lisp, it's still slow compared to native machine code. It would be nice to compile to that level, but this is a tall order, and limits portability. >>> Every version I have tried to implement vi's % operator in has failed >>> miserably in speed. I assumed that this is after you compiled the code. Lemme check this out... You mean % as in "Move the cursor to the matching parenthesis or brace."? (I had to go to the Sun 4.0 Distribution manuals for that - how do you access vi's interactive help? I also couldn't find any documentation in the `official places', which indicates how popular it is at RU.) This is how it's implemented in .../emacs/lisp/lisp.el: ;; Copyright (C) 1985, 1987, 1988 Richard M. Stallman (defun forward-sexp (&optional arg) "Move forward across one balanced expression. With argument, do this that many times." (interactive "p") (or arg (setq arg 1)) (goto-char (or (scan-sexps (point) arg) (buffer-end arg))) (if (< arg 0) (backward-prefix-chars))) The workhorse is scan-sexps, which is a primitive function, so it boogies. >> Emacs may have cool functionality, ... ^^^ That's "does". :^) >> ... but I doubt to call it a serious editor, after all the times I just >> waited for it to echo a typed character. This is ridiculous. I often run GNU Emacs on a decrepit diskless sun2 (4mb ram, ugh) under either X or suntools, running Big Programs and switching between windows often (swap swap swap), and rarely have to wait (except for the occasional swap). Your hardware situation is a nightmare, no? >> Now, TPU, that is a serious editor. I don't know anything about it, so cannot make any judgements beyond the fact that I haven't heard enough about it to know anything about it, and I follow the editing scene to some slight degree. Knowutimean, Vern? > I have noticed that GNU Emac's redisplay algorithm is about as efficient as > an "intelligent" algorithm can get ... It's fascinating to watch the tricks of the redisplay on a slow, smooth-scrolling terminal which emacs has been cruelly fooled into thinking is a fast terminal. The algorithms make the trade-off between compute time vs. screen display time, giving optimal redisplay at the expense of machine cycles. Note that the amount of redisplay work done can be seriously cut down by using `dumber' terminal definitions, and so performing on the display level of the smaller editors. Regards, [Ag] gaynor@rutgers.edu