philip@cel.cummins.com (Philip D. Pokorny) (05/08/91)
I would have to agree that we need to provide better information to HP/Apollo than 'Give us all of DM in OSF.' I don't think any of us believe it would happen so it's a waste of bandwidth. Suggestions for INPUT PAD abilities (input editing, undo/redo, cut/paste, and simple but powerfull text editing) would make the transition much easier and bring new/improved funtionality to the OSF environment. Without DM style PADs, X appears to be a glorified (and CPU expensive) way to get multiple CHARACTER based sessions. OSF is going to have a command line/shell prompt for a long time and that means character input/output and the DM PAD's go a long way to making this much easier. (er.. Looking back at this message I seem to have rambled a bit... Apologies.) Sincerely, Philip D. Pokorny :)
jason@hpcndjdz.CND.HP.COM (Jason Zions) (05/14/91)
>Suggestions for INPUT PAD >abilities (input editing, undo/redo, cut/paste, and simple >but powerfull text editing) would make the transition much >easier and bring new/improved funtionality to the OSF >environment. I admit to only passing knowledge of the use of the DM, so bear with me for one tyro question. Could you explain what editing features you'd like that you can't get with ksh in an xterm or hpterm window with a good cut-buffer manager? I suspect "undo" may be hard, but I may not understand what it does. As for input editting, ksh can be made to behave like either vi or emacs. (I know, not everyone prefers one of those two. But most know how to use one or the other.) -- This is not an official statement of The Hewlett-Packard Company. No warranty is expressed or implied. The information included herein is not to be construed as a committment on HP's part. The devil made me do it. This won't save me from the lawyers' wrath, but it can't hurt. Jason Zions The Hewlett-Packard Company Colorado Networks Division 3404 E. Harmony Road Mail Stop 102 Ft. Collins, CO 80525 USA jason@cnd.hp.com (303) 229-3800
philip@cel.cummins.com (Philip D. Pokorny) (05/15/91)
Jason Zions writes: > does. As for input editting, ksh can be made to behave like either vi or > emacs. (I know, not everyone prefers one of those two. But most know how to > use one or the other.) > -- > This is not an official statement of The Hewlett-Packard Company. No While I understand that this is not an official statement from HP, it strikes me as a fine example of what we Apollo users are really fighting when it comes to the features of Domain/OS... My whole company of 125 engineers know ONLY Aegis... Very few have seen *real* UN*X and have no idea what ksh, vi or emacs IS let alone what the key sequences are... Many have experience with PC tools that make extensive use of function keys and the mouse... For them, the Apollo keyboard with all the functions clearly labeled on each key is great tool for reducing the learning curve... Yes, I guess ksh and vi can do some of these things but why must I give up the function keys that make life so usefull and go to a cryptic set of multiple key sequences that make very little sense and were designed to accomidate the terminals of the 1960's and 70's? It's the 90's !!! Let's do it a BETTER way! We've got LARGE BITMAPPED display's and LARGE keyboards, with MICE... Let's USE them not shackle ourselves to some antiquated idea of the world... Sincerely, Philip D. Pokorny philip@cel.cummins.com As you well know, these statements are clearly my own and in no way represent the opinions of my employer (until I talk to my boss...) Watch this space for a 'snappy' discalmer in the future... :)
dennis@nosc.mil (Dennis Cottel) (05/15/91)
jason@hpcndjdz.CND.HP.COM (Jason Zions) writes: > I admit to only passing knowledge of the use of the DM, so bear with me for > one tyro question. Could you explain what editing features you'd like that > you can't get with ksh in an xterm or hpterm window with a good cut-buffer > manager? And I don't know Ksh. But can you edit a multiline command, then release it to the shell -- possibly one line at a time? Can you copy a multiline block of stuff from somewhere else and paste the whole thing into the input and have the shell read it properly? If so, will the output of each command be properly interleaved with the echoed input? I also want to be able to do a search for a character string in the output transcript, but I think this is beyond what you were asking about.... Dennis Cottel, dennis@NOSC.MIL, (619) 553-1645 Naval Ocean Systems Center, San Diego, CA 92152
nazgul@alphalpha.com (Kee Hinckley) (05/15/91)
In article <1130004@hpcndjdz.CND.HP.COM> jason@hpcndjdz.CND.HP.COM (Jason Zions) writes: >>Suggestions for INPUT PAD >>abilities (input editing, undo/redo, cut/paste, and simple >>but powerfull text editing) would make the transition much >>easier and bring new/improved funtionality to the OSF >>environment. > >I admit to only passing knowledge of the use of the DM, so bear with me for >one tyro question. Could you explain what editing features you'd like that >you can't get with ksh in an xterm or hpterm window with a good cut-buffer >manager? I suspect "undo" may be hard, but I may not understand what it >does. As for input editting, ksh can be made to behave like either vi or >emacs. (I know, not everyone prefers one of those two. But most know how to >use one or the other.) First of all the transcript is a read-only editor. Anything you can do in the normal editor you can do there. That includes search, cut, copy, scrolling.... Secondly, all of this is doable from the keyboard, and using keyboard macros. So I can make it so that a mouse click not only copies the selected text, but also brings up an editor on it. Or I can make a keydefinition that takes a wildcard, searchs backwards for one of any of my standard prompts followed by text that matches that wildcard, grabs the text, inserts it in the input buffer and leaves it there ready for me to edit. This is very akin to the search mechanisms in ksh, however ksh has one major drawback - it's ksh. In other words all those nice nifty features disappear the minute I'm in ed, or dsee, or any other command-line program or program that prompts for input. With the DM these features are available all of the time. A lot of the niceness of the DM comes from it having pad, editor and wm functionality all in one. That's what gives you the ability to copy a file name and bring up and editor on it in a particular location on the screen - all with one keydef. The other thing that people tend to like is that all the input is buffered in a separate location. You can put it on hold and go back and edit commands which haven't executed yet (or not put it on hold and type fast :-). You never get the input and the output confused. The korn shell tries to do this, but only on a one line case, and it can't do anything when it isn't waiting for input. The thing to do is find an Apollo and ask for help on dm/commands. Then take a look at the primitives and start to think about what you could do with them in an integrated environment. Things like calling icons up by name, or tagging a group of windows with a name and iconizing them all at once, or better yet, unmapping them all together and then remapping them when you want them. And you can do everything from the keyboard, no need to use the mouse unless you want to. mwm+xterm's just doesn't cut it in comparison. They're a good 5 to 6 years behind in the technology. -- 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.
kumorek@apollo.HP.COM (James Kumorek) (05/15/91)
In article <1130004@hpcndjdz.CND.HP.COM>, jason@hpcndjdz.CND.HP.COM (Jason Zions) writes: |> I admit to only passing knowledge of the use of the DM, so bear with me for |> one tyro question. Could you explain what editing features you'd like that |> you can't get with ksh in an xterm or hpterm window with a good cut-buffer |> manager? The primary difference between DM input pads and ksh command line editing is the dm input pads lets you edit the input to *any* program running in the pad, not just the input to ksh. The editing is done in the dm, not in the program that is running in the pad. This gives you the added benefit that input editing (and file editing as well) uses a common interface, no matter what program you are running. The primary disadvantage to DM pads (as I see it) is that it is not a terminal emulator or any kind, thus programs that use curses (for example) will not run correctly if you have 'rsh | telnet | rlogin | crp' to another machine. Others undoubtably have other opinions on that the 'best' and 'wrost' features of the DM are. Jim Kumorek Apollo Computer, Inc. - A subsidiary of Hewlett Packard kumorek@apollo.hp.com
dan@dc.cpsc.ucalgary.ca (Dan Freedman) (05/16/91)
For those who are interested, I have a program which lets you do emacs-style editing of input to ANY program you happen to be running under it. Basically, it uses a pseudo-tty to insert itself between your terminal/window and a shell, which it starts for you under itself. You can then edit input to the shell or any program running under it. It is smart enough to get out of the way when programs such as emacs are running. It detects the assertion of RAW mode to make the determination of whether or not to get out of the way. It does not do cut and paste with the window system, although this could be added. It also does not do the multi-line input thing that the DM does. Basically, you can only edit a line until you press return. One nice result of using the program is that commands end up magically placed next to the shell prompt, even when you type many commands in at once. This is the same as what the DM does. This program has been in use for many years, and is very portable. It has been used on suns, vaxes, and apollos. The only bad thing is that tabs show up on the screen as ^I while editing, although they display correctly once return is pressed. Please send mail if you are interested, and I will put the source up for ftp. It's not very big, is quite efficient, and is extremely reliable. Dan Freedman -- U. of Calgary Computer Science Dept., 403 220-7299 2500 University Dr. N.W., dan@cpsc.ucalgary.ca Calgary, Alberta, Canada. T2N 1N4 VE6DFM
rand@hwcae.cfsat.honeywell.com (Douglas K. Rand) (05/16/91)
** kumorek@apollo.hp.com (James Kumorek) on 15 May 91 18:41:55 GMT ** in [Re: DM in OSF] writes: In article <1130004@hpcndjdz.CND.HP.COM>, jason@hpcndjdz.CND.HP.COM (Jason Zions) writes: |> I admit to only passing knowledge of the use of the DM, so bear |> with me for one tyro question. Could you explain what editing |> features you'd like that you can't get with ksh in an xterm or |> hpterm window with a good cut-buffer manager? James> The primary difference between DM input pads and ksh command James> line editing is the dm input pads lets you edit the input to James> *any* program running in the pad, not just the input to ksh. James> The editing is done in the dm, not in the program that is James> running in the pad. Most of what has been requested for editing features can be had by using Epoch. (Epoch being a X windows implementation of Emacs.) Command history for all programs (not just the shells), a built in editor for pointing to files and clicking mouse button 3, and more. The only things that Epoch/Emacs won't do that the DM does, is keep you input synchronized with your prompt and editing multiple input lines. I can live with out the first, and there are (difficult) ways to do the second. (Sorry, this wasn't supposed to be an advertizement.) -- 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
dan@dc.cpsc.ucalgary.ca (Dan Freedman) (05/17/91)
In article <1991May15.181212.16095@cpsc.ucalgary.ca> dan@dc.cpsc.ucalgary.ca (Dan Freedman) writes: > >For those who are interested, I have a program which lets you do >emacs-style editing of input to ANY program you happen to be running >under it. Basically, it uses a pseudo-tty to insert itself between >your terminal/window and a shell, which it starts for you under >itself. You can then edit input to the shell or any program running >under it. It is smart enough to get out of the way when programs such >as emacs are running. It detects the assertion of RAW mode to make >the determination of whether or not to get out of the way. Ok, the response has been very positive, so the sources for ile, my input line editor, are now up for FTP. You can get them from cpsc.ucalgary.ca (136.159.3.1, log in as anonymous with your e-mail address as password) in a directory called pub/dan The file is called ile.tar.Z Once you have uncompressed and untarred the file, a README file will direct you as to how to make the binary. Dan Freedman -- U. of Calgary Computer Science Dept., 403 220-7299 2500 University Dr. N.W., dan@cpsc.ucalgary.ca Calgary, Alberta, Canada. T2N 1N4 VE6DFM
dan@dc.cpsc.ucalgary.ca (Dan Freedman) (05/17/91)
In article <1991May16.182558.6875@cpsc.ucalgary.ca> dan@dc.cpsc.ucalgary.ca (Dan Freedman) writes: >You can get them from cpsc.ucalgary.ca (136.159.3.1, log in as >anonymous with your e-mail address as password) in a directory >called pub/dan > >The file is called ile.tar.Z PS: Don't forget to put ftp into image mode (type in image or binary at the ftp prompt). Dan -- U. of Calgary Computer Science Dept., 403 220-7299 2500 University Dr. N.W., dan@cpsc.ucalgary.ca Calgary, Alberta, Canada. T2N 1N4 VE6DFM
nazgul@alphalpha.com (Kee Hinckley) (05/17/91)
In article <1991May15.181212.16095@cpsc.ucalgary.ca> dan@dc.cpsc.ucalgary.ca (Dan Freedman) writes: > >For those who are interested, I have a program which lets you do >emacs-style editing of input to ANY program you happen to be running Unfortunately your From: address is unreplyable. I'd be very interested in your software if you could mail me a copy (I don't have FTP access and bitftp just closed it's doors). -kee -- 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.
steve-t@hpfcso.FC.HP.COM (Steve Taylor) (05/18/91)
In /comp.sys.apollo/ dan@dc.cpsc.ucalgary.ca (Dan Freedman) / writes: > For those who are interested, I have a program which lets you do emacs-style > editing of input to ANY program you happen to be running under it. ---------- This sounds kind of like 'ied', a new utility for HP-UX 8.0 which provides ksh-style editing for any program run inside it. According to the man-page, you can even run ksh inside ied to get an environment where all commands by default have ksh-style editing. Regards, Steve taylor NOT A STATEMENT, OFFICIAL OR OTHERWISE, OF THE HEWLETT-PACKARD COMPANY.
rand@hwcae.cfsat.honeywell.com (Douglas K. Rand) (05/19/91)
** 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!randnazgul@alfalfa.com (Kee Hinckley) (05/19/91)
> 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.
tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (05/21/91)
> I admit to only passing knowledge of the use of the DM, so bear with me for > one tyro question. Could you explain what editing features you'd like that > you can't get with ksh in an xterm or hpterm window with a good cut-buffer > manager? o A consistent editing-model across the entire user interface. o Multi-page cut and paste with Mark/Copy Mark/Cut. o Consistent backscroll and side-to-side panning for text and to a certain degree graphics. Thomas Gilg tomg@cv.hp.com
jason@hpcndjdz.CND.HP.COM (Jason Zions) (05/22/91)
The "ied" command, supported in HP-UX 8.0, which lends ksh-like editting features to any program, gives you some of what command pads give you. Not all, granted. A version of ksh, called keysh, also gives you the ability to make the other keys on the keyboard do things. With some work and use of various X utilities, some of the things you had hard-wired keys for can be brought back. Jazz
nazgul@alphalpha.com (Kee Hinckley) (05/22/91)
In article <101020047@hpcvlx.cv.hp.com> tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) writes: > o Multi-page cut and paste with Mark/Copy Mark/Cut. That reminds me. I've noticed that people in the DM context rarely used cpf to copy a text file when they are editing. You just cut and paste the contents of the file. I've often done that on files that were megabytes in size. That doesn't work too well using vanilla X cut-and-paste! -- 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.
philip@cel.cummins.com (Philip D. Pokorny) (05/23/91)
Jason Zions of HP Colorado Networks Division writes... With some work and use of various X utilities, some of the things you had hard-wired keys for can be brought back. Ok... There's been lots of talk about ways to get the DM functionality into OSF... WHO's gonna' do the work...??? Is HP going to say "The tools are there, all you have to do is write a macro, or create a file, or ..." and make EVERY user do the same work over and over again (or do without) or will HP INVEST in it's customer base and do the work ONCE for all the Domain/OS users? (I realize that Jason can't answer this, but I don't want us to loose sight of the fact that someone needs to pull all the pieces together... It is a very different thing to say something is 'technically possible' versus 'done and available for FTP/purchase/request...') Later, Phil philip@cel.cummins.com :)
mzw_t@hpujsda.HP.COM (Matsuzawa Takashi) (05/24/91)
> > o Multi-page cut and paste with Mark/Copy Mark/Cut. > > That reminds me. I've noticed that people in the DM context rarely > used cpf to copy a text file when they are editing. You just cut > and paste the contents of the file. I've often done that on files Yes. Pasting to the input pad is our usual way of feeding text data to prf, sort, etc. that takes input from standard input. --- Takashi Matsuzawa Japan CPO Yokogawa Hewlettt-Packard E-Mail: mzw_t@hpujisa.yhp.hp.com