Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!pasteur!ucbvax!UHHEPG.BITNET!RALPH From: RALPH@UHHEPG.BITNET Newsgroups: comp.os.vms Subject: Re: Re: Problem with TPU affecting VT-220 terminal behavior Message-ID: <8802151613.AA01263@ucbvax.Berkeley.EDU> Date: 10 Feb 88 20:02:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 96 Date: 10-FEB-1988 11:24:18.07 From: Ralph Becker-Szendy RALPH AT UHHEPG To: B_INFOVAX,RALPH Subj: Re: Re: Problem with TPU affecting VT-220 terminal behavior I didn't get the original message (is the moderator listening out there ?), but i have two cents worth on the problem: >From: Sir Xetwnk >Subject: Re: Problem with TPU affecting VT-220 terminal behavior > >I've seen the precise problem you describe, under similar circumstances - i.e. >attaching back and forth from one process to another. > >What's happening is this: the user is working in EVE, in Insert mode (or the >equivalent; in EDT this would be the Keypad Mode default). He then attaches to >the DCL process. DCL doesn't know that the user has been anyplace (other >process) else since issuing the previous DCL-process command, so doesn't >realize that the terminal's PHYSICAL characteristics have been altered by EVE >to be specific, EVE has switched the TERMINAL SETUP from the DCL default of >"overstrike" mode, to EVE-compatible "insert" mode. So DCL thinks the terminal >is in "overstrike" mode, while it is actually, physically in "insert" mode. First of all, to really find out what the terminal is doing, you need a terminal which can display the insert mode setting in the status line (time to praise my Falco 5220). Then the following observations are real easy: (they were all done with the default terminal mode settings for a VT200) Strangely enough, DCL >> does not << use insert mode when you are in the "SET TERM/INSERT" mode. It rather rewrites the command line when you insert characters. Using the terminal monitor mode, i saw it do the following: - Delete character (the DEL key) uses "BS blank BS" - Cursor left uses "BS" (and no cursor control sequence) - character overwriting is obvious - character insert writes the new character, writes the rest of the line, does a "ESC [ K" (erase to end of line) and moves back with "BS"s. To me it seems to be very stupid that DCL doesn't use the insert mode, but as usual i can't search the soul of the VMS developers. The version of EDT we have here (but i never use it) does all its inserting the same way DCL does it (a little test reveals that), which again seems to be very stupid, in particular if you are trying to edit over a modem line. Now EVE (i should rather say TPU, because that's where these functions are handled) is more intelligent: when you are in "overstrike" mode it >>never<< switches insert on. When you are in insert mode and you are at the end of the line, it leaves the terminal in overstrike, too. The reason seems to be that some terminals (in particular the VT241) are really slow in insert mode, even if you just have to shift out blanks. It only uses insert mode when you are actually "inserting" new characters in the middle of a line. By the way, EVE (ar again, rather TPU) is quite a bit more efficient in screen handling (that is one of the reasons why i use it exclusively, speed becomes important with 44 lines on the terminal at 9600 baud). What "vanilla" SMG does ? i didn't bother to write a test program to figure it out. I guess it will behave like TPU (after all TPU uses SMG for all its terminal IO). Now, Chris explanation of going into insert mode at the wrong time ... >(By the way, the weird visual effect you describe is due to the way "delete >character left of cursor" is actually performed by VMS so that "what you see >is what you get": You hit DEL, sending ASCII 127 to VMS. VMS returns an ASCII >8 (backspace to sit on the character being deleted), ASCII 32 (space; BLANK >OUT the character from the display, "deleting" it visually), and another ASCII >8 (move cursor back to recover from the space character moving the cursor). >In Overstrike mode, this has the effect you are used to. However, in insert >mode, the space character INSERTS BETWEEN characters, rather than WIPING AWAY >a character, hence you see everything that was originally there, which you >have "deleted", with spaces between them. Your command line is being edited >properly nonetheless; but the discrepancy between what DCL EXPECTS the >terminal to do, and what the terminal ACTUALLY does, causes a breakdown of the >visual effect. "What you see is NOT what you get," in this case.) .. is right. His cure is unfortunately wrong ... >Hitting control-A in DCL toggles command-line input mode between insert and >overstrike mode, including the corresponding adjustment of terminal physical >characteristics. Hitting control-A TWICE when you return to DCL should fix >your problem, by sending first the "enter insert mode" sequence (no effect; >terminal is ALREADY in insert mode), then the "enter overstrike mode" sequence >(which will fix the terminal). .. because DCL will never switch the terminal to insert mode (or out of it). I actually don't know any nive way to cure the problem (short of going into EVE again and exiting the right way): >If EVE allows the user to toggle Insert/Overstrike modes, exit to DCL should >be flawless if done from the midst of Overstrike mode. That's what science is all about ... explaining a trivial detail in great depth ! Ralph Becker-Szendy RALPH@UHHEPG.BITNET University of Hawaii / High Energy Physics Group (808)948-7391 Watanabe Hall #203, 2505 Correa Road, Honolulu, HI 96822 "Hawaii - it's not just for tourists. People actually live and work there."