Comment 20 for bug 1297051

>"Applications running inside the terminal should not be able to resize/move/iconize/raise the window."

That is a completely valid choice. However \e[?40h fails to implement that. All it does is force the host to send one extra escape sequence (if it knows that it needs to send it). As such therefore I don't really see the point of \e[?40h. However it would have been harmless if it had been "high" by default i.e. defaulted to allowing resize. As previously stated, noone should change this now. A change now would just cause even more compatibility problems.

The logical and simple way of implementing that choice is as a configuration choice within the terminal emulator. PuTTY does that. Under Terminal/Features there is an option "disable remote-controlled terminal resizing". If the *user* sets that option then it behaves as you want. The host really can't resize the terminal no matter what escape sequences it sends.

However in our environment we would never want that option. Most screens get by with a 24x80 window but some screens *need* 132 columns and some screens *need* more than 24 rows, so when the user goes into one of those screens the host will resize the window to the required size and when the user exits such a screen, the host will resize back. This is somewhat visually distracting but the alternatives - within the limitations of a character-cell terminal interface and of our application - are worse still or not practical for us.

I have no problem if someone wants to add the above configuration option, as long as it is off by default. However I have no use for such a configuration option. So I won't be requesting it.

In fact, if anything, we have the opposite problem i.e. fat-fingered users who accidentally resize their terminal window and then raise support calls because the application doesn't work properly. :-)