From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11787 invoked from network); 9 Jun 1999 18:09:39 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Jun 1999 18:09:39 -0000 Received: (qmail 8648 invoked by alias); 9 Jun 1999 18:09:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6562 Received: (qmail 8641 invoked from network); 9 Jun 1999 18:09:24 -0000 From: "Bart Schaefer" Message-Id: <990609180833.ZM32477@candle.brasslantern.com> Date: Wed, 9 Jun 1999 18:08:33 +0000 In-Reply-To: <199906091710.CAA21834@pop1.ngy.3web.ne.jp> Comments: In reply to Tatsuo Furukawa "Re: COLUMNS/LINES environment variable" (Jun 10, 2:13am) References: <199906091710.CAA21834@pop1.ngy.3web.ne.jp> X-Mailer: Z-Mail (5.0.0 30July97) To: Tatsuo Furukawa , zsh-workers@sunsite.auc.dk Subject: Re: COLUMNS/LINES environment variable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 10, 2:13am, Tatsuo Furukawa wrote: } Subject: Re: COLUMNS/LINES environment variable } } Current zsh code is } applied following patch. This comes from zsh-workers/4447. [...] } This patch makes zsh stranger than original 3.0.5. Because, } environment variable COLUMNS/LINES are different from shell variable. Yes, as I said, this was an oversight. When LINES/COLUMNS are assigned, adjustwinsize() is called before the export step. This makes fixing the bug more complicated, because adjustwinsize() can't do the export itself when the reason for the call is that LINES/COLUMNS are changing. The other complication is that the current code resets the (internal) value of COLUMNS when LINES is assigned, and vice versa, but again does not peform the export. Tatsuo's patch handles the export, but I think it's actually bad that assigning to either of LINES/COLUMNS causes both of them to change. (This gets tricky because the tty driver's idea of the rows/columns shouldn't get messed up either, but of course the only way to set either of those is to set both.) Oh, and if somebody can tell me why zrefresh() has to be called even when the new values are the same as the old ones, I'd appreciate knowing. } [ vi ($Revision: 78.2.1.8 $ HP-UX 10.20) ] } } When startup, } } 1. If COLUMNS/LINES are exist, this value is used. If terminal is } resized, TIOCGWINSZ value is used (COLUMNS/LINES are ignored). } } 2. If COLUMNS/LINES are not exist, TIOCGWINSZ value is used. If } terminal is resized, TIOCGWINSZ value is used. vim (Vi IMproved 5.3) uses the TIOCGWINSZ values at startup but then reverts to COLUMNS/LINES any time an external program is run (e.g. via a shell escape). This annoys the heck out of me, because I frequently start my mail GUI from an 80x24 xterm and then launch an 80x48 xterm from there to edit messages -- which means LINES is wrong. } [POSIX shell (HP-UX 10.20)] } } (same as vi) I suppose we could actually go so far as to test at configure time for a POSIX environment (say, the same check that's now used to find out if we have POSIX termios) and define a constant that could be used to tell if zsh can always believe TIOCGWINSZ. } When startup, } } 1. If COLUMNS/LINES are exist, use this value. } 2. If above is void, use TIOCGWINSZ value. } 3. If above is void, use termcap/terminfo value. } 4. If above is void, use 80*25. I'm sticking with 80x24, but otherwise I agree, and this should be what presently happens (at startup). } When resized, } } 1. TIOCGWINSZ value is used. (Even if COLUMNS/LINES are exist.) Yes. I believe we can assume that if SIGWINCH is sent/received, then the tty driver has valid numbers. The important point is that COLUMNS/LINES should also be exported if they are in the environment, which is what is not happening yet. } "After some command", } } 1. If COLUMNS/LINES are different from internal columns/lines } value, COLUMNS/LINES are used. No, that can't be right. No external command can modify COLUMNS/LINES in zsh's environment, so the only way the environment could be different is if the internal values were previously read from the tty, in which case it would be wrong to go back. } Bart> Probably in that last case we could see whether the tty driver } Bart> values of lines/columns actually changed since the last } Bart> TIOCGWINSZ, and elect to believe them in that event. } } Your idea is also good for me. :-) That's the one I've been fooling with. See remarks above about the complications. } Bart> The correct course for the user is to explicitly set } Bart> LINES/COLUMNS if he knows the correct values [e.g. eval } Bart> $(resize)] or to unset them if he knows that the terminal driver } Bart> has the right values. } } This has following inconvenience [...] Actually, explicitly assigning them a value of zero will force zsh to read the values from the tty driver, which is then correctly exported. So instead of "eval $(resize)" just "LINES=0 COLUMNS=0" will fix it. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com