peter@ficc.ferranti.com (Peter da Silva) (08/30/90)
To begin with, a minor flame: WHY THE HELL DID DEC BOTHER PUTTING A TERMINFO CLONE IN VMS IF THEY DIDN'T PLAN TO USE IT? Does anyone have an editor for VAX/VMS that uses the screen management library, and thus can take advantage of the fact that SMG now supports non-DEC terminals? EDT and TPU are both hardcoded for VTxxx terminals. (sigh) -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
tp@mccall.com (08/30/90)
In article <POJ5HH9@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > To begin with, a minor flame: > WHY THE HELL DID DEC BOTHER PUTTING A TERMINFO CLONE IN VMS > IF THEY DIDN'T PLAN TO USE IT? > > Does anyone have an editor for VAX/VMS that uses the screen management > library, and thus can take advantage of the fact that SMG now supports > non-DEC terminals? EDT and TPU are both hardcoded for VTxxx terminals. They put it in because everyone was whining for them to do it, but it is too slow to use for anything intensive as editting. It is used for other things, which is why I know it is so slow (the debugger leaps immediately to mind). The bottom line is DEC really doesn't want you using non-DEC terminals. I hear gnu emacs works very well on non-DEC terminals on VMS (it must therefore not use SMG either!). -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
davis@pacific.mps.ohio-state.edu ("John E. Davis") (08/31/90)
In article <68.26dcd5d9@mccall.com> tp@mccall.com writes: In article <POJ5HH9@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > To begin with, a minor flame: > WHY THE HELL DID DEC BOTHER PUTTING A TERMINFO CLONE IN VMS > IF THEY DIDN'T PLAN TO USE IT? > > Does anyone have an editor for VAX/VMS that uses the screen management > library, and thus can take advantage of the fact that SMG now supports > non-DEC terminals? EDT and TPU are both hardcoded for VTxxx terminals. They put it in because everyone was whining for them to do it, but it is too slow to use for anything intensive as editting. It is used for other things, which is why I know it is so slow (the debugger leaps immediately to mind). The bottom line is DEC really doesn't want you using non-DEC terminals. I hear gnu emacs works very well on non-DEC terminals on VMS (it must therefore not use SMG either!). -- Terry Poot <tp@mccall.com> The McCall Pattern Company I personally think that Gnu emacs on VMS writes to the screen MUCH more efficiently than edt or eve even on vtxxx terminals. This is one of the major reasons that I prefer emacs over any VMS editor. For example I am reading the news from home using emacs (on unix but the essential argument follows through). When I read the above included message and I decided to follow up on it, instead of repainting the included message, emacs just left it on the screen but shifted it right three characters! Hence, I'd say a factor of at least ten was gained in achieving the desired effect. At 1200 baud this is significant. If you want to test this yourself and you have emacs on your system then do the following: 1. Edit a file using eve. 2. Now make two windows and note how eve does it. 3. Do the same in emacs and see how it should be done. (factor of two faster) -- John bitnet: davis@ohstpy internet: davis@pacific.mps.ohio-state.edu
peter@ficc.ferranti.com (Peter da Silva) (08/31/90)
In article <68.26dcd5d9@mccall.com> tp@mccall.com writes: > In article <POJ5HH9@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > > WHY THE HELL DID DEC BOTHER PUTTING A TERMINFO CLONE IN VMS > > IF THEY DIDN'T PLAN TO USE IT? > They put it in because everyone was whining for them to do it, but it is > too slow to use for anything intensive as editting. Why is this? Curses and terminfo are certainly fast enough, even on a .7 VAX MIPS 68000 system with 30 users. In fact we have been running our VAX through a vt100-to-termcap conversion program I wrote that runs fast enough on an 80386 in 80286 mode. > The bottom line is DEC really doesn't want you using non-DEC terminals. And people wonder why I don't like DEC. > I hear gnu emacs works very well on non-DEC terminals on VMS (it > must therefore not use SMG either!). You mean it must use SMG... Anyone, back to the point. Has anyone got anything we can use to talk turkey to a VAX from a Televideo 950? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
leonard@arizona.edu (08/31/90)
It is not at all the case that SMG is "too slow" for an editor. The version of MicroEmacs used at the University of Arizona uses SMG and is plenty fast. (ua_source:[micro-emacs] on Osprey.Telcom.Arizona.EDU.) Aaron
jym@remarque.berkeley.edu (Jym Dyer) (08/31/90)
.-. |I|'ve seen an editor based on SMG. It was blindingly slow, `-' though some of this is due to its trying fancy things (like drawing ephemeral boxes over top of things). .-. |N|ote that Emacs uses termcap but not curses. Probably because `-' curses has limitations similar to SMG's. <_Jym_>
lennartb@lne.kth.se (Lennart Boerjeson @ KTH/LNE, The Royal Inst. of Tech.) (08/31/90)
In article <Y9K57Q9@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: >Anyone, back to the point. Has anyone got anything we can use to talk >turkey to a VAX from a Televideo 950? >-- >Peter da Silva. `-_-' >+1 713 274 5180. 'U` >peter@ferranti.com DEC-programs that don't use SMG probably still use the SCR$ routines. They are "obsolete" now, but DEC apparently still uses them... Anyway, if you declare your terminal be "foreign" via SET TERM/FT1 thru /FT8, SCR will load SYS$SHARE:SCRFT.EXE which would implement the actual routines. Somewhere I have a package in source for SCRFT, the prototype came from DEC. If someone is interested, mail me. (The package is in total disorder, so don't expect some clean installation guide... I didn't write it, I don't know the details.) But rememeber that SCR is OFFICIALLY OBSOLETE. !++ ! Lennart Boerjeson, System Manager ! School of Electrical Engineering ! Royal Institute of Technology ! S-100 44 Stockholm, Sweden ! tel: int+46-8-7907814 ! Internet: lennartb@lne.kth.se !--
peter@ficc.ferranti.com (Peter da Silva) (09/01/90)
In article <JYM.90Aug30182054@remarque.berkeley.edu> jym@remarque.berkeley.edu (Jym Dyer) writes: > .-. > |N|ote that Emacs uses termcap but not curses. Probably because > `-' curses has limitations similar to SMG's. Cute graphics. It's easy to convert a terminal program to use Termcap/Terminfo... it's mostly a matter of changing the hardcoded escape sequences. It's a lot harder to make it use Curses... it's often a complete rewrite. Since Emacs already does decent screen updating it's a bit redundant. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
mikes@ingres.com (Mike Schilling) (09/04/90)
From article <POJ5HH9@xds13.ferranti.com>, by peter@ficc.ferranti.com (Peter da Silva): > To begin with, a minor flame: > WHY THE HELL DID DEC BOTHER PUTTING A TERMINFO CLONE IN VMS > IF THEY DIDN'T PLAN TO USE IT? > Minor dousing: SMG is used many places in VMS, most notably in the windowing display for the Debbugger. ---------------------------------------------------------------------------- mikes@rtech.com = Mike Schilling, Ingres Corporation, Alameda, CA Just machines that make big decisions, Programmed by fellows with compassion and vision. -- Donald Fagen, "IGY"
sommar@enea.se (Erland Sommarskog) (09/05/90)
Just for the record, there is a Swedish company, Excosoft, who
has an editor, Exco, which uses SMG. Exco is also available for
some Unix machines and PCs. It was born on VMS and its default
key bindings are those of EDT with some differences.
It's some years since I used Exco, but let me say that is an
excellent concept. Those who have installed LSE 3.0, will recognize
some ideas. Exco is an hierarchical editor, which means you can
expand and compress lines as you like (hence the name EXpand COmpress)
to keep visible what you like to see for the moment. You can link
a line to another line, which may be a line in another file.
Also, Exco allows you write code and pseudo-code in the same file.
In difference to LSE 3.0 this is achieved by using a special format
for Excofied files, meaning that a compilation must be preceeded by
an extraction operation. a quick task.
It comes with a formatter and a sort of environment, Excoshell.
Excoshell is stupid, but you don't have to use it. The editor/
formatter is excellent for writing technical documentation like
specifications and similar, since the hierarchical structure
saves you from all that .hl noise. The link facility makes
references to pages or chapters tremendously simple.
Exco is programmable. The language is not as powerful as the one
of TPU, but is in most cases sufficient for tailoring your own
editor. Special filters are still best written with TPU.
Performance as I recall is worse than TPU, but not disastrous.
Probably in par with or better than LSE. I don't know about
performance on Unix and MS/DOS.
Several big companies in Sweden uses Exco in their VMS environment.
Last time I asked, two years ago, they didn't have an email address.
Their hardcopy-mail address is:
Excosoft AB
Box 1270
S-164 28 KISTA
SWEDEN
+46-8-7520380
I have no commercial interest whatsoever in Excosoft. I just think they
have a good product.
--
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
In the real world there are no colours.karsten@tfl.dk (09/05/90)
In article <2487@naucse.cse.nau.edu>, jdc@naucse.cse.nau.edu (John Campbell) writes: > From article <JYM.90Aug30182054@remarque.berkeley.edu>, by jym@remarque.berkeley.edu (Jym Dyer): >> .-. >> |I|'ve seen an editor based on SMG. It was blindingly slow, >> `-' though some of this is due to its trying fancy things (like >> drawing ephemeral boxes over top of things). >> <_Jym_> > > [...] > > Anyway, we use NED (NAU Editor) here nearly as much as we use EVE. NED > is about 10-20% less efficient in CPU usage than EVE doing the same tasks. > Moving off our VAX 11-730 and up to a VAX 6310, however, made the 10% or > so penalty moot. Last time I looked at full-blown emacs (back when it > was first ready for VMS) it was much more than a 20% penalty over EDT. > By the way, NED uses less memory to do the same tasks as EVE (and I wasn't > being all that careful about memory when I designed it). One could argue > that TPU wasn't a good tool to write editors with either. I think the discussion about whether or not TPU should use SMG is based on a wrong assumption. The assumption is that TPU should use either SMG or some routines written for TPU for writing on terminals. The screen management routines are not build into TPU. They are loaded by LIB$FIND_IMAGE_SYMBOL and are placed in SYS$SHARE:TPU$CCTSHR.EXE and SYS$SHARE:TPU$DECWSHR.EXE which support VT%%% terminals and DECwindows respectively. You can specify any image file, which define the right symbols as the value of the EDIT/TPU/DISPLAY qualifier. EDIT/TPU/DISPLAY=DECWINDOWS is a shorthand for EDIT/TPU/DISPLAY=SYS$SHARE:TPU$DECWSHR.EXE. DEC or anybody with VAX/VMS micro fiches could write a shareable image which does screen management for TPU and is based on SMG. Then the users with Digital terminals could use TPU$CCTSHR, and all others could use the SMG based version. IMHO providing support for third party terminals without supporting at least one editor on these terminals is of no value. Karsten Nyblad TFL, A Danish Telecommunication Research Laboratory E-mail: karsten@tfl.dk
martinh@gp.co.nz (Martin D. Hunt) (11/29/90)
In article <2487@naucse.cse.nau.edu>, jdc@naucse.cse.nau.edu (John Campbell) writes: > > I guess it's time to admit something. I wrote an SMG based editor as > part of a larger package that was a joint project between my university [rest of message deleted] I thought I has seen this message before, then I checked the date - 1st Jan 91 - is someone on the network running a time machine? :-) -- -------------------------------------------------------------------------------- Martin D. Hunt GP Print Limited USEnet address : martinh@gp.co.nz Wellington PSI address : PSI%0530147000028::martinh New Zealand Phone : +64 4 4965790 --------------------------------------------------------------------------------
jdc@naucse.cse.nau.edu (John Campbell) (01/01/91)
From article <JYM.90Aug30182054@remarque.berkeley.edu>, by jym@remarque.berkeley.edu (Jym Dyer): > .-. > |I|'ve seen an editor based on SMG. It was blindingly slow, > `-' though some of this is due to its trying fancy things (like > drawing ephemeral boxes over top of things). > <_Jym_> I guess it's time to admit something. I wrote an SMG based editor as part of a larger package that was a joint project between my university (Northern Arizona University) and DEC. I started just before TPU and EVE came out and I spent some time evaluating TPU before deciding upon SMG. You see, we needed verticle windows and a few other goodies that SMG would support that TPU couldn't. Also, I didn't want to give up total control of my data structures as the editor was to be callable from inside other applications we had in mind. Anyway, we use NED (NAU Editor) here nearly as much as we use EVE. NED is about 10-20% less efficient in CPU usage than EVE doing the same tasks. Moving off our VAX 11-730 and up to a VAX 6310, however, made the 10% or so penalty moot. Last time I looked at full-blown emacs (back when it was first ready for VMS) it was much more than a 20% penalty over EDT. By the way, NED uses less memory to do the same tasks as EVE (and I wasn't being all that careful about memory when I designed it). One could argue that TPU wasn't a good tool to write editors with either. Unfortunately, for me anyway, DEC never really looked at the editor and work on our "writing tools" that was going to use this editor came to a stop when I got transferred to another group. Still, the editor itself had a few nice features, and I tend to use it exclusively on VMS probably out of a sense of loyalty. Unsophisticated users like it, sophisticated users start looking for things that were on my "to be done" list, like regular expressions. Theoretically you can contact me for a beta agreement and, if the right person at your institution signs it, I can release my work to you. This agreement says you'll send me some feedback about what you like and don't like about the package every year or remove it from your system. In reality, no one has ever been very interested in taking a fair look at the package and I'm too busy elsewhere to implement much if anything new on the editor. It does, however, work with other terminals. It is a *very* close clone to EVE because I liked that interface for beginning users. It is not overtly slow, screen updates do not look terrible and, in fact, some recent VMS upgrades have improved NED's behavior in screen updating. Someone a few years ago analyzed SMG vs his own package and showed quite a few places where SMG could have been improved in terms of efficiency and functionality. Other than this very well done comparison, I haven't seem much better than SMG for a dumb terminal package. I've been trying to port NED to curses and have decided that curses was aptly named (like decode an arrow key on BSD curses or make a nice routine to pop up a window, move it around and then remove it and recover the window(s) underneath). Rumor has it that vi doesn't even use curses. Anyway, stop maliagning SMG and don't believe the rumor that the TPU team started about SMG being too slow to use in an editor. It's a little slower, but it really does work just fine. Think about it, most of the time you're inserting text on a line anyway. If you are on the end of the line then you can post a VMS read for the amount of characters you need and be as efficient as anyone else! Of course, you have to be willing to write your editor to detect some of these special cases (like when a window can scroll and when you have to fake the scrolling) but that's really the job of the person writing the editor. Final advice? Peter, get micro-emacs if there is a version that uses terminfo or termcap. I know it's frustrating and I know that someone wrote a termcap to termtable (VMS) translator, but few people have access to an SMG based editor. Mine is "available" but it is EVE-like, not emacs or vi like and it's currently unsupported (although in heavy use at our site). -- John Campbell jdc@naucse.cse.nau.edu CAMPBELL@NAUVAX.bitnet unix? Sure send me a dozen, all different colors.