Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!hwcae.cfsat.honeywell.com!rand From: rand@hwcae.cfsat.honeywell.com (Douglas K. Rand) Newsgroups: comp.sys.apollo Subject: Re: DM in OSF Message-ID: <9105190244.AA07656@hwcae.cfsat.honeywell.com> Date: 19 May 91 02:44:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 160 ** nazgul@alfalfa.com (Kee Hinckley) on 19 May 91 01:49:32 GMT ** in [Re: DM in OSF] writes: Kee> First of all the transcript is a read-only editor. Anything you can Kee> do in the normal editor you can do there. That includes search, Kee> cut, copy, scrolling.... 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 "transcirpt". One draw back is that your transcript is not read-only. You can change it. (For those times you want to make it look like it worked. ;-) Kee> Secondly, all of this is doable from the keyboard, and using Kee> keyboard macros. 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. Kee> I can make it so that a mouse click not only copies the selected Kee> text, but also brings up an editor on it. 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. Kee> Or I can make a keydefinition that takes a wildcard, searchs Kee> backwards for one of any of my standard prompts followed by text Kee> that matches that wildcard, grabs the text, inserts it in the Kee> input buffer and leaves it there ready for me to edit. This works even better in Epoch than it does in the DM. Since you full access to the keys, your previous commands are kept in a list to bring them back. Epoch doesn't have to search the transcript for your prompt, it just cycles through the list. Kee> This is very akin to the search mechanisms in ksh, however ksh Kee> has one major drawback - it's ksh. In other words all those nice Kee> nifty features disappear the minute I'm in ed, or dsee, or any Kee> other command-line program or program that prompts for input. Just like in the DM, Epoch always stays there. You can go into any other application and Epoch will still remember your commands. Kee> With the DM these features are available all of the time. A lot Kee> of the niceness of the DM comes from it having pad, editor and wm Kee> functionality all in one. 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 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. Kee> That's what gives you the ability to copy a file name and bring Kee> up and editor on it in a particular location on the screen - all Kee> with one keydef. I don't think you need the WM to help you bring up a file to edit. you need the assistance of the terminal emulator. Certainly xterm, hpterm, and mterm won't do it. Kee> The other thing that people tend to like is that all the input is Kee> buffered in a separate location. You can put it on hold and go Kee> back and edit commands which haven't executed yet (or not put it Kee> on hold and type fast :-). You are right. I haven't figured a way to do the hold functionality in Epoch yet. I'm still trying, but it isn't easy. The only thing that causes Epoch to behave like this is if you select a region of multiple lines and past them into your shell window. You can edit all the lines until you press the return key. At that time they get sent to the shell. But once you press the return key, the current line goes. Kee> You never get the input and the output confused. The korn shell Kee> tries to do this, but only on a one line case, and it can't do Kee> anything when it isn't waiting for input. Yup. This looks real nice and neat. Epoch makes a half hearted attempt at this, and it works for only one line ahead. That is, you can be typing the commands to your next command before the last one finishes, but you can't hit the return key until it is done. Otherwise your input and the prompts won't be in sync. Everything works just fine, it just doesn't look very organized. Kee> Things like calling icons up by name, or tagging a group of Kee> windows with a name and iconizing them all at once, or better Kee> yet, unmapping them all together and then remapping them when you Kee> want them. The WM that comes the closest to being like the DM is GWM, from Colas Nahaboo. It has a built in Lisp interperter to extend the functinoality of the WM. I just finished last week writing a next-window function that behaves like the DM commands tni, tn, tlw, and ti. It goes about it differently, but you get the same effect. I also have commands to move windows around into different quadrants of the screen on key presses. I'm slowly (very slowly :-) working on putting the best of the DM into GWM. Kee> And you can do everything from the keyboard, no need to use the Kee> mouse unless you want to. I agree. Once I reach for the mouse, I feel that I'm slowing down unless I can keep my hand on the mouse for a while. I moving back and forth from the mouse to the keyboard. Don't get me wrong, pop-up, pull-down, and all the rest of the menus are good. They are easier than looking for the manual to see what the command is. But if I know the command, I can type it easier. Kee> mwm+xterm's just doesn't cut it in comparison. They're a good 5 Kee> to 6 years behind in the technology. I'll go along with you on xterm (and the rest of the *term's). All they are is a vt100 that can scroll a little. (And I mean a little, not very far at all.) Have you ever tried to use the mouse to copy a command down to rexecute it when it was wider than your window? If it scrolls up and down, why can't it scroll right and left? How about when you resize your window to be smaller, and all that text gets cut off? As far as mwm goes, there are more good things about mwm than there are bad. I'd rather use mwm than the DM. (But given a choice, let me have gwm!) One fo the things about the DM that has always made me upset was that there was only one cursor. I could never keep that stupid arrow lined up in the input pad. It kept moving when I bumped my desk. It is also too inflexable when it comes to colors. (Especially now at 10.3. HP/Apollo really screwed up the color maps. I can't make the pad background black with out making the text in DDE & Emacs black too.) I also dislike having the cursor warp around the screen all the time. I don't really want the cursor to move unless I move the mouse or force it to move with the next-window key. Another good thing that came along with X is the idea of a virtual root window. I like being able to scroll my root window around, and place windows off the screen, either completly or partially. I hope this didn't turn out to be a DM bashing session, it was not meant to be. I just wanted to point out that there are ways of getting the good things from the DM into X windows. And that there are a couple of things the DM could do better too. 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. [PS: Epoch is a X windows based version of Emacs. It is based on Emacs 18.55, and it only supports X windows. GWM is an ICCCM compliant WM available from export.lcs.mit.edu.] -- Douglas Keenan Rand Honeywell -- Air Transport Systems Division Phone: +1 602 436 2814 US Snail: P.O. Box 21111 Phoenix AZ 85036 NSFnet: rand@hwcae.cfsat.honeywell.com UUCP: uunet!asuvax!apciphx!hwcae!rand