greim@sbsvax.UUCP (Michael Greim) (08/23/88)
This is a report of a bug in vi, version 3.7, on systems with signal SIGTSTP and subsequent "fg" (csh) or signal SIGCONT. The bug was brought to my attention by a posting by Ian Donaldson (see References above) Symptoms: - start vi - take a normal text file - make a line with more than 80 characters, or whatever your terminals maximum number of characters might be - position the cursor in this line after column 80 (or whatever ...) - stop vi with ^Z (works even if you have another suspend char) - continue it again with "fg" from csh, of any other means --> either - screen is empty, next char will redraw screen - or there may be an error message "internal error in vgoto" and vi seems to hang Diagnosis: The situation after vi is restarted is similar to initial startup. Therefore things are internally tweaked to use the same code. This code sets a variable (splitw) which normally indicates that the cursor is in the echo area (the last line on the screen, where the users inputs ex-like commands or search strings). When vi is restarted it looks at the column number and thinks it is in an extension line of the echo area. Therefore it holds back an update in order not to loose the data in the echo area. This results in the screen being blank and the cursor being in the correct column but at the bottom line of the screen. Therapy: In the restart routine only try to redraw the screen on your own if vi is really called at interrupt level. Normally ^Z is read in like any character then things are setup up as if "stop" was typed from the keyboard and the redraw is handled by the code, to which the restart routine will return. If the stop was really triggered by an interrupt, then it can be necessary to redraw the screen. This might result in a double update of the screen. Apply the following context diff's. onsusp is fitted with a parameter so it can tell from whence it is called. *** ex_cmds.c.old Tue Aug 23 17:10:42 1988 --- ex_cmds.c Tue Aug 23 17:04:08 1988 *************** *** 602,608 eol(); if (!c) ckaw(); ! onsusp(); continue; #endif --- 602,608 ----- eol(); if (!c) ckaw(); ! onsusp(-1); continue; #endif *** ex_subr.c.old Tue Aug 23 17:10:54 1988 --- ex_subr.c Tue Aug 23 17:08:36 1988 *************** *** 948,954 /* * We have just gotten a susp. Suspend and prepare to resume. */ ! onsusp() { ttymode f; int omask; --- 948,955 ----- /* * We have just gotten a susp. Suspend and prepare to resume. */ ! onsusp(nsig) ! int nsig; { ttymode f; int omask; *************** *** 978,984 vcnt = 0; } vdirty(0, LINES); ! vrepaint(cursor); } } #endif --- 979,996 ----- vcnt = 0; } vdirty(0, LINES); ! /* mg, 23.aug.88 ! * if we are called with nsig == -1 then we have been called ! * from ex_vmain regularly. The code to which we return will ! * handle the redrawing of the screen. ! * If we are called with something else, then we are called ! * on interrupt level from somewhere in the program and ! * it might (!) be necessary to redraw the screen. ! * The call of vrepaint here caused a bug if cursor was not in ! * the first part of a line with depth>1 when ^Z was input. ! */ ! if (nsig != -1) ! vrepaint(cursor); } } #endif If this code seems to break something, tell me, -mg -- UUCP: ...!uunet!unido!sbsvax!greim | Michael T. Greim or greim@sbsvax.UUCP | Universitaet des Saarlandes CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 voice: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany # include <disclaimers/std.h>