Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!mips!pacbell.com!att!ucbvax!alfalfa.com!nazgul
From: nazgul@alfalfa.com (Kee Hinckley)
Newsgroups: comp.sys.apollo
Subject: Re: DM in OSF
Message-ID: <910519135949.2636@sony.alfalfa.com>
Date: 19 May 91 04:59:49 GMT
References: <9105190244.AA07656@hwcae.cfsat.honeywell.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 67

> A lot of what you like in the DM can be done by using Epoch to runs
> your shells in. You get a full blown editor to navigate through your
Yep.  I've said before that a workable solution would be a modified
Mwm, Korn Shell and Epoch combination.  (Workable on an 040 that is.)
However those items would presumbably have to be shipped and supported,
and the integration of the three (particular with regards to using
the gray keys) would have to be done.

> I think it is easier to do keyboard macros in Epoch/Emacs than it is
> with the DM. But then I've been doing Lisp programming for a couple of
> years.
Neither is easy for the beginner, but I think that the curve on
DM keydefs starts off easier (but then gets much harder when you
start doing fancy stuff).

> Hmm, I've never thought of editing a selected region, but then why
> not? I do have the shift-read and mouse-button-3 commands defined so
> that the file under the cursor/point is brought into Epoch. And I use
> it hundreds of times a day.
Actually I left out a level of indirection - I meant edited the
file name it refered to :-).

> This also causes a lot of trouble too. If you ask your editor to do
> something for you, like search a 12 Mbyte file for a string, your WM
> goes to sleep too. You loose all the good things about having a multi
This is where the DM excels.  Everything is *fast*.

> processing workstation. It also prevents you from choosing other
> editors, window managers, terminal emulators. I think we have all had
> problems with HP/Apollo's vt100 emulator.

Once upon a time there was a project at Apollo.  You've seen pieces
of it.  There's the Rectangle Manager and Input DeMultiplexor, and
the Text Management Library.  What you never saw was QUICHE (the
Quick User Interface Command Handling Environment) and the window
manager and pad components.  The project was going to replace the
DM with a set of modular components.  The extension language would
have hooks in the IDM so that any program that a user wrote could
be extended - either by intercepting the input stream, or by using
a class-like mechanism where cogniscent applications would export
a table of routines that could be called.  Thus you could define
a set of key definitions for manipulationg editors and have them
work in all editors that supported the Editor class.  There was
going to be a separate window manager, editor and pad manager,
and it was all going to play together like the DM.

It was canned.

> I don't think you need the WM to help you bring up a file to edit. you
You do if you want to be able to mark a region on the screen for it
to appear in, or bring it up in a particular location - although
if all of your editors take a standard set of arguments to specify
the window location you could get by without it.

> If any of you are running either Epoch or GWM, I'd be happy to send
> copies of my JLRDM code. But be fore-warned: It isn't trivial to set
> up either Epoch or GWM from scratch.
I'd be interested in a copy.


Alfalfa Software, Inc.          |       Poste:  The EMail for Unix
nazgul@alfalfa.com              |       Send Anything... Anywhere
617/646-7703 (voice/fax)        |       info@alfalfa.com

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.