Re: COLUMNS/LINES environment variable

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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