SCHOMAKE@HNYKUN53.BITNET (Lambert Schomaker) (02/05/88)
[] The following message shows, once again, there is something wrong with TPU > Subj: EDT-emulation in TPU > I'm without a TPU manual and I'm trying to find out how to >modify EDTSECINI so that it emulates EDT a little better. > > 1: How do I make UP and DOWN work so that it uses screen columns > .......... > ........................ The "VAXTPU EDT Keypad Emulator" > handbook says it's possible but does not go into detail. > 2: How do I get FIND to search for the end-of-line as part of a > search string. I use end-of-line and form-feed a lot in > >mike, mcguffey@muvms1.bitnet If we step back in history, we'll remember: 1) The old RT-11 EDIT. Character-oriented and powerful in that sense but not very user-friendly, (remember the ESC terminator?). 2) RSX's (and DSM's) EDI. Line oriented, much more user-friendly but we lost the ability to fiddle with end_of_lines. 3) EDT. Full-screen/Line-oriented/Character oriented. Now here we have a powerful editor, for interactive work as well as for off-line text processing. The only functionality I missed was the "wild" change from EDI: "C/The...man/Nothing", and, somewhat later, multiple windows, after I had seen Emacs. 4) TPU/Eve. Full-screen/Multiple-Windows. Is this really an improvement? In my opinion Eve is only a very rudimentary editor. Maybe you can get used to its user interface, but it doesn't have the inbuilt power of EDT. Naturally, you can make your own routines but that is not what I am hired for (I won't even speak about TPU's verbosity here, as compared to EDT change subcommands). It looks like we have reached a stage where you can only speak of _changes_ in software instead of _improvements_. As long as there is no good EDT emulator written in TPU, provided and supported by DEC, with multiple windows as _additional_ functionality, I will still be using the old EDT. However, I do not doubt the power of TPU as a text processing language, but I think its complexity (syntax, compiling etc) puts to much of a burden on the user, even if he's a good programmer. Why learn TPU as a language? We already have Snobol, Icon, Pascal, C and even Fortran-77... I would be very dissappointed in DEC if EDT (i.e., the full functionality of EDT) is going to be dropped in VMS V5.x. Lambert Schomaker schomaker@hnykun53.bitnet
OBERMAN@ICDC.LLNL.GOV ("Kevin Oberman, LLNL, 422-6955, L-156", 415) (02/06/88)
>If we step back in history, we'll remember: > ... >3) EDT. > Full-screen/Line-oriented/Character oriented. > Now here we have a powerful editor, for interactive work as well as > for off-line text processing. The only functionality I missed was > the "wild" change from EDI: "C/The...man/Nothing", and, somewhat later, > multiple windows, after I had seen Emacs. > >4) TPU/Eve. > Full-screen/Multiple-Windows. > Is this really an improvement? In my opinion Eve is only a very > rudimentary editor. Maybe you can get used to its user interface, but it > doesn't have the inbuilt power of EDT. Naturally, you can make your > own routines but that is not what I am hired for (I won't even speak > about TPU's verbosity here, as compared to EDT change subcommands). > >It looks like we have reached a stage where you can only speak of _changes_ >in software instead of _improvements_. As long as there is no good EDT >emulator written in TPU, provided and supported by DEC, with multiple windows >as _additional_ functionality, I will still be using the old EDT. > >However, I do not doubt the power of TPU as a text processing language, but I >think its complexity (syntax, compiling etc) puts to much of a burden on the >user, even if he's a good programmer. Why learn TPU as a language? We already >have Snobol, Icon, Pascal, C and even Fortran-77... > >I would be very dissappointed in DEC if EDT (i.e., the full functionality >of EDT) is going to be dropped in VMS V5.x. FLAME ON! At the Anaheim DECUS symposium there was a session comparing various VMS editors (Editor Wars). The clear winners were EMACS (EMACS Make A Computer Slow) and TPU (EVE). The list of things which could be done in EVE and EMACS, but not EDT, was truely impressive. The most significant, in my opinion, are multiple windows and the ability to bring DCL commands and there responses into the session. The last thing I want to do is go back to EDT! On the other hand, if you want to keep using EDT, go right ahead. It certainly works (slowly). If you don't want to learn TPU, don't bother. I can believe that you have better things to do. But don't toss out silly straw men to justify your outrage. There is no need, I suppose, to learn TPU. It's enough like Pascal that it is very easy to learn, but even without learning TPU you can still use the LEARN and DEFINE KEY EVE functions to customize the editor and it's keypad. EVE is an editor. And, I believe it's a pretty good one. TPU is a text processing language. I think it's pretty good, though far from perfect. If you only want to edit, use EVE. If you need specialized text processing, use TPU. The argument that learning a new language after already learning several is totally irrelevant. That's like saying that you shouldn't have to learn a new language for an AI application when you already know Pascal. Pascal is simply not a good language for all applications. If you want to text processing, don't try FORTRAN. It may be possible, but it's rather impractical. I must confess that I still feel more comfortable prograsmming in FORTRAN than any other language. That doesn't mean I deny the value of C, Pascal, or other languages. They are better in many respects. I could even survive if FORTRAN disappeared from my system. And I would become much more proficient at C very quickly. It is even possible that my overall job perfomance would improve. But I'd still be upset at not having `good old' FORTRAN. Finally, who said anything about EDT being dropped in V5.x? I heard some rumours that EVE would become the default editor in V5, but not even that from any of the developers. If EDT reaches the usage levels of SOS in V2, I don't doubt that it will fade away. And many people will be upset. But while SOS had some really nice features, can you really justify the expense of supporting it for the very few people who used it when DEC finally dropped support? If EDT ever reaches that level, I suppose you will have to get by without it, too. But with EDT's current popularity I don't see that happening until FULL EDT functionallity is made available from EVE. FLAME OFF! I realize editors are very personal things. They are many peoples most common tie to an operating system. If I had had EDT pulled out from under me before I had gotten used to EVE and TPU I would have been more than a bit miffed. But there is absolutely no doubt in my mind that EVE is a major step up from EDT. And if the developers were to read your letter, deceide that you were right, and drop EVE, I would feel just as upset as you do about any possible demise of EDT. R. Kevin Oberman Lawrence Livermore Natioal Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: These are my personal opinions. They do not have any relation to those of my employers, who don't really care about what editor I use. They may not even know what an editor is.
IVANOVIC%VAXR@circus.llnl.GOV ("Vladimir Ivanovic, x3-7786") (02/06/88)
I disagree with Lambert Schomaker's (schomaker@hnykun53.bitnet) opinion of TPU. I find Eve to be an Easy, Extensible and Efficient VAX Editor (EVE), as the developers claim. For me, the LEARN command alone is worth the investment in time to learn Eve. I can't see ever using EDT again. I have not spent much time with actual TPU code, but I have looked at it, hacked at parts and incorporated the Eve_Plus extentions into my environment. I feel comfortable with its structural similarity to Pascal. I wonder how much of the resistance people seem to have towards new products is due to their investment in learning to use the old product. The most fanatical users seem to use the editors with incredibly long and steep learning curves like TECO, EMACS and WordStar. I picked up Eve basically without a manual, with only the online help, in what, a few days at most. Since I'm used to a Macintosh environment where a user familiar with the standard Macintosh interface can run an unknown application without looking at the manual, I feel that there is no excuse for programs that are not easy to learn. Then the only question is one of functionality. Does it do what you need? Can you customize it to your personal needs? Does it perform well enough? -- Vladimir
rrk@byuvax.bitnet (02/07/88)
Tell me how to do two things in TPU and I'll be much happier about it:
How do you search for/replace the end of line, and is it possible to prevent
TPU from reading in the entire file before you decide to go to the bottom?
Thanks.
Ray Whitmer
AMMON::RAYdko@calmasd.GE.COM (Dan O'Neill) (02/09/88)
In article <8802060240.AA01341@ucbvax.Berkeley.EDU> IVANOVIC%VAXR@circus.llnl.GOV ("Vladimir Ivanovic, x3-7786") writes: >The most fanatical users seem to use the editors with incredibly long >and steep learning curves like TECO, EMACS and WordStar. I picked up >Eve basically without a manual, with only the online help, in what, a >few days at most. [This is not a flame, please don't take it as one] Ok, first of all, I may be a fanatic. EMACS may not be the "best" or end-to-all-editors editor, but there are a lot of us out here who use it for various reasons. Two of EMACS's greatest advantages, aside from programability, are its relatively standard user interface and the ability to run on a variety of hardware. EMACS has been around since about '76 or '77 (maybe earlier?) and has changed relatively little from a users point of view. The internal programming language has gone through several changes, but the basic functionality and user interface have remained the same. There are some key-stroke differences between various versions, generally minor. In my experience, another of EMACS's primary strengths is that it runs on just about every piece of hardware made today. I currently use various flavors of EMACS on VAX/VMS, VAX/Ultrix, SUN/BSD, Pyramid/BSD & SYS V, Apollo/Aegis, DEC-20/TOP-20 and IBM-PC/AT/PS 2 systems. Each of these systems have varying keyboard layouts and display technologies, yet EMACS runs, and runs well, on each of them. With hardware and software changing so rapidly, one needs a still point of familiarity. EMACS provides a common editing environment for numerous platforms. The learning curve for the basic editing commands in EMACS is not that long or steep. Included with the editor is a very good tutorial where you learn to edit by doing. Is it not better to learn a single editor, rather than a new editor for each different machine? One learning curve as opposed to several? This article probably doesn't belong in comp.os.vms. I will end my discussion here as editors are sort of religion oriented. Thanks for listening, and may you use the editor of your choice for as long as you like. -- Dan O'Neill dko@calmasd.GE.COM GE Calma R&D ...!sdcsvax!calmasd!dko
dave@wsccs.UUCP (VAX Headroom @ The End of the Galaxy) (02/12/88)
In article <8802051623.AA17951@ucbvax.Berkeley.EDU>, SCHOMAKE@HNYKUN53.BITNET (Lambert Schomaker) writes: > The following message shows, once again, there is something wrong > with TPU ... ... ... > It looks like we have reached a stage where you can only speak of _changes_ > in software instead of _improvements_. As long as there is no good EDT > emulator written in TPU, provided and supported by DEC, with multiple windows > as _additional_ functionality, I will still be using the old EDT. > > However, I do not doubt the power of TPU as a text processing language, but I > I would be very dissappointed in DEC if EDT (i.e., the full functionality > of EDT) is going to be dropped in VMS V5.x. Here at WSC Computer Science we use the LSEDIT (Language Sensitive) editor. I believe this editor is written in tpu, though I am not sure about this. It certainly provides all the capabilities of TPU. It also emulates EDT very well (you can also get EVE emulation), plus it provides many new features. It (along with TPU) is also much more efficient than EDT. As for EDT dying in 5.0, I dont know if they will actually drop it, but they say in the 4.6-4.7 release notes that they are going to fix EVE to look a lot more like EDT. I would like to know what they are planning to do with the LIB$EDIT system service if they drop EDT, perhaps they will alter EVE such that it can be called in exactly the same way through LIB$EDIT. If you work in a programming environment I highly recommend LSEDIT. +-----------------------------------------------------------------------------+ | | Dave E Martin | DISCLAIMER: Been Cancelled | | /\ | "...between the streets of | $ opinion/mine/noUinTech | | / \ . /\ | Dallas, and the beaches of |----------------------------| | / \/ \/\/ \ | Miami ... THIS was Max | ...!ihnp4!utah-cs!utah-gr! | | / U i n T e c h \ | Headroom's finest hour." | uplherc!sp7040!obie! | | | --Max Headroom | wsccs!net23.dnet!dave | +-----------------------------------------------------------------------------+
terrell@musky2.MUSKINGUM.EDU (Roger Terrell) (02/12/88)
In article <70rrk@byuvax.bitnet> rrk@byuvax.bitnet writes: >Tell me how to do two things in TPU and I'll be much happier about it: > >How do you search for/replace the end of line, and is it possible to prevent >TPU from reading in the entire file before you decide to go to the bottom? I'm not certain what you mean when you say "search for/replace the end of line", but if you want to, you can tell TPU (EVE anyway) to go to the bottom before it has read the entire file in. While it is loading the file (your screen is still dark, etc.) go ahead and press the DO key and type BOTTOM as if it were already loaded. It does not seem to place the command into the type-ahead buffer, but actually comes up with the file positioned at the bottom. This works for the FIND key as well. --Roger -- Roger Terrell Muskingum College ...cbosgd!musky2!terrell (UUCP) New Concord, OH 43762
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (02/17/88)
> How do you search for/replace the end of line To search for end-of-line, use the built-in SEARCH. For example, <DO>TPU POSITION(SEARCH(LINE_END,FORWARD)); For a replace, you'd need something like: <DO>TPU POSITION(SEARCH(LINE_END,FORWARD));COPY_TEXT("new text"); MOVE_HORIZONTAL(1);APPEND_LINE; > Is it possible to prevent TPU from reading in the entire file before you > decide to go to the bottom? TPU reads the whole file into virtual memory as part of READ_FILE. You can't get there from here. It could be worse: on some UNIX systems, ed wants to read the whole file into PHYSICAL memory.
rrk@byuvax.bitnet (02/20/88)
I believe I was unclear on both of my requests. I meant I would like TPU
better if:
You could prevent TPU from reading in the entire document unless it becomes
necessary (EDT does this by default. It only reads in the parts of a file
that it has to. Once it has read it, it holds it i memory as does TPU,
but if I want to look at the first few pages of a huge listing with editor
functionality, I don't have to wait for EDT to read the entire listing before
I can look at the first page. What I meant was that it ONLY reads in the
entire document if you do something like going to bottom of document forcing
the entire document to be accessed.
The second item was as follows:
In EDT, I can search for an end of line. This means, I can replace double
empty lines with single empty lines. I would simply replace "^M^M" with a
paste buffer containing a single empty line. I can specify a high repeat
count and make this into a global search and replace. Or I can globally
replace "^M^I" with a paste buffer containing an empty line, which removes
the first leading (or if I do it differently all leading) tabs from lines,
but leaves those internal to the line.
Or I can replace "^M" with a paste buffer containing a line "$EQU " to place
$EQU at the beginning of each line. There are many more applications requiring
the ability to replace the end of line character.
The following quirks apply when replacing end of line in EDT:
If you are replacing a single "^M" with a large repeat count in order to
do a global replace, go to the end of document and do this in a reverse
direction, because there is always a single "^M" at the end of document,
and search and replace in forward direction on a "^M" by itself will cause
a limitless number of replacements to occur at end of document. Also, you
do not type "^" and "M" in your replace strings. You hit the return key
which echos as a "^M" or the tab key which echos as a "^I", etc.
If anyone knows how to do this in EVE or LSE (simply, without writing
TPU routines, I would greatly appreciate it. I cannot use an editor which
cannot replace the end of line as an entity.
Thanks
Raydarin@laic.UUCP (Darin Johnson) (02/29/88)
EVEPLUS has a "regular expression" type of find and replace. Matching
end of line is supported, but I haven't played with it too much. This
would be a good starting place to see if you can do what you want with
end of lines. If it isn't powerful enough as is, then you can look at
the source and add whatever functionality you need (looking at the eveplus
source, it looked fairly easy to simple mods to, so don't be put off if
you don't know TPU)
--
Darin Johnson (...ucbvax!sun!sunncal!leadsv!laic!darin)
(...lll-lcc.arpa!leadsv!laic!darin)
All aboard the DOOMED express!