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).
For example, I don't run my browser maximized, because I don't want web pages in landscape; acres of margin or very long lines - neither choice is good. The viewport of my browser is nearly square (1500 x 1300).
Terminals don't work great with very long lines either; man, less etc. adjust to terminal width making lines harder to read.
My scratchpad app I keep for notes is generally notepad shaped, i.e. taller than it is wide, but not as wide as a terminal window.
My password manager (KeePass2) is the only other really common app. I don't interact with it very often other than via hotkey.
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.
Arguably in the Windows world this is even worse. The default reflex in Windows is to maximise every window you have. At least with on OSX the default way of making a window bigger is just to "zoom" it to a better size.
Also regarding tiling terminal.app you should really have a look at GNU Screen. You can use it to create multiple sessions in one window that are split in a 'sane' way.
I think a lot of terminals just set that as the default window width. No real reason for it, I usually snap to half the screen width immediately anyways. That turns out to about 105-120 characters width. Some people might just not resize it most of the time. Especially on Mac where efficient window management just isn't a thing.
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.
Terminal.app - if there was one app that I wished would resize itself to handle the widest possible line, that is it. Alas, it just zooms to fill the entire screen - which is somewhat comedic at 10 pt Courier on a 2560x1600 30" Monitor whose longest line in the scrollback-buffer is 75 characters.
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.
I work almost exclusively with this setup: Dual split screens, shell on left, browser on right.
The reason I comment is to share what took me too long to realize. If you want to resize the two full screen apps, the experience is much smoother if your browser is in focus first. Click browser, then drag to resize.
Something to do with the terminal trying to keep to character-width bounds, I think.
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.
I rly love 0.9 version.
The only thing that annoys me is resizing. When you open a tab and then you increase the window size, the actual terminal size is not increases with it. At least on my computer :-)
So I always need to first make the terminal fullscreen and then open tabs.
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.
Not all of the window is usefull all of the time. Sometimes only the terminal half of the IDE is, sometimes just the editor half is. Same to the browser, sometimes you only need to look at the console and not the website (while testing something over the IDE). Resizing windows is actually way more annoying than just aranging them the right way so you can alway trigger the useful half.
I think most tilling WMs fails to realize how annoying windows that keep changing size are. If they do, the entire concept of automatic tiling seems way less useful.
I use sizeup[1] to maximize the terminal (or any other app) with a keystroke, instead of native full screen. It works across all applications that allow window resizing, and has handy shortcuts for "half" full screen, which is great to position, say, a browser and editor next to each other across the whole screen.
Which reminds me, I really will go and pay my 13 bucks for it now, it's more than worth it. But the free version is fully functional with just an occasional nag screen.
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.
I find the current Windows 10 terminal vastly superior to anything default on Mac or Linux... Take resizing the window for instance, Windows adjusts the content text, whereas Mac does not seem to handle this well.
EDIT: It is possible you are on an outdated version of Windows, or have upgraded and still retain your old settings.
Be sure QuickEdit Mode is enabled, as well as Ctrl key shortcuts.
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).
reply