Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!acorn!john From: john@acorn.co.uk (John Bowler) Newsgroups: comp.windows.x Subject: Re: how does xterm tell vi the window size Keywords: xterm vi Message-ID: <1060@acorn.co.uk> Date: 12 Oct 89 13:04:23 GMT References: <253@zeek.UUCP> <1227@virtech.UUCP> <286@enuxha.eas.asu.edu> <1233@virtech.UUCP> <1055@acorn.co.uk> <16231@umn-cs.CS.UMN.EDU> Reply-To: john@acorn.UUCP (John Bowler) Organization: Acorn Computers Ltd, Cambridge, UK Lines: 57 As several people have pointed out my description of the algorithm used by vi to determine terminal window size was incorrect - vi looks at the tty line settings (on a BSD/Sun OS system) *FIRST*. Therefore my explanation of the original posters problem was also incorrect. In fact if the vi in an rlogin session (on a BSD/Sun OS system) assumes the wrong window size it can only be because the information is not stored correctly in the tty line (either the wrong driver is in use - not the new one - or the information has not be stored correctly or has been altered). The likely explanation is that the rlogin (on the original machine) or the rlogind (on the remote machine) have failed to communicate the window size information at all. This, at least, is relatively easy to test (because it should be entirely independant of X) - simply rlogin to the remote machine from an xterm (or other terminal/terminal emulator) with the correct tty row/column settings and examine the settings on the client machine (using ``stty all''). If the rows/columns values are 0 they haven't been transmitted for some reason (some difference of opinion between the remote rlogind and the local rlogin, or perhaps the remote login does not support the ``-r'' option which rlogind uses to preserve the rows/columns values?) If the values have changed (eg to 80x24, as in the original article) the likely explanation is that they were set to 0, then a ``tset'' command in the users ``.login'' reset the values from the termcap information (notice that tset does not reset the values (in BSD4.3) if they are not zero!) In <16231@umn-cs.CS.UMN.EDU>, brsmith@umn-cs.CS.UMN.EDU (Brian R. Smith) writes:- > Re-sizes pass just fine through rlogind in all of [these operating systems], but SunOS 3.5 > *and* 4.0.3 vi's ignore SIGWINCH for some reason. Looks like only > Sequent got it right, and they don't even have a proprietary windowing > system... Guy Harris () provided me with an explanation of this:- ``... try resizing the window when you're in the middle of reading a big file; you'll discover that the SIGWINCH is handled by "longjmp"ing out of whatever it's doing and jumping back into the main input loop. This is somewhat rude when e.g. reading in a file, since it stops reading in part of the file and doesn't tell you about it. That's why the SunOS "vi" doesn't do this - SIGWINCHes are delivered when a window is raised in SunView, so it's even more likely to shaft you.'' Personally I prefer vi to respond to SIGWINCH - I resize my windows a lot (for example, I have window zooming bound to a function key under twm, and I quite often use this to expand a vi session to full screen size). Eirik Fuller () also pointed out that the xterm termcap which I posted contains both IC (insert multiple characters) and im/ei (enter insert mode/exit insert mode) sequences. This seems to be incorrect - we replaced the ``ic'' with the ``im/ei'' pair because it can speed up character insertion in vi a lot, leaving in the IC is an error (although one which causes problems with relatively few applications apparently). John Bowler (jbowler@acorn.co.uk)