vi-bug: internal error in vgoto. A fix.

[Michael Greim]

	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 at sbsvax.UUCP           | Universitaet des Saarlandes
CSNET: greim%sbsvax.uucp at Germany.CSnet| FB 10 - Informatik (Dept. of CS)
ARPA:  greim%sbsvax.uucp at uunet.UU.NET | Bau 36, Im Stadtwald 15
voice: +49 681 302 2434               | D-6600 Saarbruecken 11, West Germany

# include <disclaimers/std.h>