That solution sounds even more hacky. Just like I expected resizing my iterm2 window causes glitches because it's text reflowing. I love that feature, but I realize this isn't a problem for all terminals.
That behavior is pretty common with many terminals. Off the top of my head, I know the default macOS Terminal and Windows Terminal both behave like that where you need to change the default dimensions in the settings.
I personally prefer having the dimensions set to a default size and then resizing specific windows that require more space. But it should at least be an option to have it remember resizes.
Resizing the window does not change anything, it makes things worse as the messages now will not be displayed properly. Try it. Resize the window, you will notice the parts whose size does not change at all.
Why is that in a 80x24 terminal I have everything on screen while typical Electron applications require one workspace per application otherwise the crucial data becomes ugly? Just let us resize bits or make them collapsible or something.
Ah, I forgot to mention: the resize -if the terminal-window is smaller- will still happen, but as long as the two sessions are operating on a different window they can be of different size.
As a followup, my terminal windows are rarely the same size as my browser windows. I don't like resizing my browser windows in general because the browser will remember the new size, even though it was meant as a once-off window. So having a browser-sized terminal doesn't seem like a very good experience.
Additionally, it doesn't even work right. In a screen-controlling app like vim it seems fine, but in the normal shell, once I enter enough text to use more than a screen, the bottom-most line is actually off the window (even if I scroll down).
Hey, that's actually in version 2 as well! It frustrated me too, even made a checkout of the source to fix it myself, and then found that it's in the advanced options. Go to preferences -> advanced and all the way to the bottom there is "Terminal windows resize smoothly.". Set that to yes, and it will resize to the edges of the screen.
One thing about tabs, which ironically has come up now for Microsoft Windows Terminal, is that they do not fit at all well with the idea of application-resizable terminals, which has been the widely case for terminal I/O since the days of 80/132 column application-switchable terminals back in the 1970s. If (just to pick a mild example) one tab is a 24-line terminal and another is a 25-line terminal, they aren't the same size in the GUI.
Line up a row of real terminals, and of course they do not constrain one another, size-wise. Indeed, back in the 1990s the DTTerm terminal emulator pioneered the terminal emulators' abilities for applications to set any arbitrary size (within reason) for a terminal emulator.
I did a quick review of terminal emulators in light of this, and varyingly tabbed terminal emulators do not support application resizing (DECSLPP/DECSNLS/DECSCPP) at all or support it in limited, or at least odd (compared to real terminals), ways. Konsole, possibly the best of the bunch, implements resizing properly, leaving large margins when the requested terminal screen size does not match the GUI window size, but triggers a GUI resize whenever a tab receives the input focus back, so application-requested size changes do not last if one switches amongst tabs. One tabbed terminal emulator author is actively opposing the idea that terminals should be resizable by applications emitting these control sequences, completely reversing course from DTTerm's innovation.
The problem for Windows Terminal is compounded by the fact that it isn't just supporting terminal I/O applications, it is supporting console I/O applications. In console I/O not only can applications set the screen buffer size at whim, they can also set the window rectangle. Not supporting either is a huge and very noticable step backwards, by over three decades, for Windows TUI applications that Windows Terminal is aimed to be compatible with.
A tabbed UI is not a universally unproblematic thing when it comes to terminal emulators. (-:
I'm in the same boat, rarely re-sizing windows, and I'd do the same thing, but I use Tmux and terminal Vim and using the mouse there just doesn't work in my terminal emulator. (I use st[0] on Linux. It probably would work in iTerm on Mac, but I haven't tried.) It also may not work due to Tmux being configured with mouse support.
That is actually pretty interesting, thanks for linking!
I still dont understand how this was not "fixed" years ago, sure some config windows have fixed widths because it makes sense, but something as a terminal obviously needs the ability to grow (or shrink), especially after they introduced sticky windows and people actually used "tiling"
You are right regarding resizability - putty resizes naturally, it's cmd.exe which doesn't allow full screen resizing with a mouse (at least on windows xp).
But, the wrap issue is annoying - you can't do a ps -auxwww , see that the line length is too long, and the resize the window and have your text rewrap. (At least on putty 0.6, the version on my vm instance)
Don't get me wrong - I love putty, and it's one of the first two or three things I put on every windows system. I love that you can use it as a serial console as well - great for consoling into cisco routers - particularly now that Microsoft in it's infinite wisdom has dropped hyper terminal. In fact, Putty is better than terminal.app in that regard - Terminal.app doesn't do console ports!
But, if I am spending many thousands of hours at the console, Terminal.app (or, possibly iTerm) is going to make me happier and more productive than putty. Probably not 2x more productive, or even 50% more productive - but certainly 10%, which is enough for me.
> Funnily enough, on Windows their new Terminal supports it also if you dig in the settings a bit.
Can you permanently resize it? Last I tried it, it was slow and I didn't see how to make it fullscreen or behave predictably on multimonitor setups, so I couldn't actually use it.
Oh man, they left out the part I was hoping to find out more about!
> it's good form to have a function called resize() or similar that you run on program start and later when the terminal window is resized. while there is a horrible way to do this with ANSI escapes, it's better to just bite the bullet and learn how to use ioctls and termios.
I wanted to know about the horrible ANSI escape sequences to send that can query the window size. Afaict one has to read from the terminal to get the answer--but these are control sequences that could be inserted into the normal stream--when, where, how?
My only very minor issue with screen is that it ignores window resizing escape codes. I have my .vimrc setup to resize on start/exit and screen doesn't care at all. I am totally vain I know.
I wrote an ncurses frontend to the the ticketing system used at a job one time. One of the users complained that if they resized their terminal window rapidly, larger and smaller, that is would crash.
Sorry for being off-topic but what I dislike the most about Gnome Terminal is that it opens a small window by default (like 1/4 of my screen size) and even if you resize it, it doesn't remember the size after restart. It turns out you need to go to settings and manually specify how many columns and rows do you want.
reply