mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (04/05/91)
In article <1991Apr04.193344.16407@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
why the devil should an editor compile, read mail, or read news?
emacs is just a visual shell.
"So what's your point?"
Actually, I'd tend to claim that to qualify as "visual shell", it
would have to have an interface much more palatable to novice users.
But that's pretty trivial.
As to why an editor should do those things - why should a shell have
built-in editor functionality? Those shells are becoming popular. The
answer is the same in both cases - because in doing these things, you
actually wind up spending a lot of time editing text. Having the
"same" editor in all those cases is a good thing.
There are three ways to get this:
1) The emacs approach - make everything happen inside the editor. That
means you only have one set of editing routines to maintain. It also
means you have on large program.
2) The tools approach - make everything do it's own trivial editing,
and let the user invoke the real editor for anything serious. It means
you don't have any single monster programs. It also means you have to
maintain multiple copies of the editing code(*).
3) The IPC approach - provide a moderatly bright editor that allows
external programs to extract text from buffers, and insert text into
buffers (among other things) via IPC. You don't have any single large
program. You have one copy of the editing code to maintain.
(*) The tools approach with a readline library leaves you at
maintaining only two copies of the editing code. With shared
libraries, you even wind up with only two copies in memory.
<mike
--
When all our dreams lay deformed and dead Mike Meyer
We'll be two radioactive dancers mwm@pa.dec.com
Spinning in different directions decwrl!mwm
And my love for you will be reduced to powder