Change:
} // Ensure the size is not reduced beyond the minimum, otherwise weird things can happen <del> if (sizes[index] + amount < SPLIT_PANE_MIN_SIZE) { amount = SPLIT_PANE_MIN_SIZE - sizes[index]; } else if (sizes[indexToChange] - amount < SPLIT_PANE_MIN_SIZE) { amount = sizes[indexToChange] - SPLIT_PANE_MIN_SIZE; </del> <ins> if (sizes[index] + amount < Constants.SplitPaneMinSize) { amount = Constants.SplitPaneMinSize - sizes[index]; } else if (sizes[indexToChange] - amount < Constants.SplitPaneMinSize) { amount = sizes[indexToChange] - Constants.SplitPaneMinSize; </ins> } // Apply the size change

Discussion:
Previously the terminal could be resized fairly quickly, to see what's going on and then hide it again (with 2 lines still visible). With the new update however, it can only be resized by one line per keystroke. So in order to use the terminal adequately, there are 10 - 20 keystrokes required, which is unacceptable (in my opinion). It would be great, if you could specify "args" for the command which control how many lines the terminal is resized by. Similar like the cursorMove command: Thanks for consideration, Floyd Haremsa <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. -→
I'm not sure what you mean. changing the height of the panel? https://user-
Yes, changing the height of the panel, but with keyboard shortcuts. Previously it worked pretty well (changing the height by lets say 10 lines, I don't quite remember). But now you can only resize by one line at a time (per hitting the keyboard shortcut), like this: https://user- and that is just way too slow and inefficient. This way I'm forced to resize it with the mouse (which is also too slow) or having it open all the time, which is bad on small screen sizes. Sorry for not having it clarified enough earlier.
we think this is related to the increase view size change - thoughts ?
This is indeed caused by The new behavior is actually the intended behavior, but the terminal is in full control if it wants to have a number-of-lines-based resize setting.
I am also affected by this and it is crazy to work mouseless, resizing terminal is not viable with keyboard like this. Any work around?
how many rows would you expect it to change?
3-4 would be nice
I'd say about 7 - 10 lines at a time. But if I can control it my self, that's even better.
Also being affected by this. The terminal now resizes by 1 line at a time.

Previously it was 9 lines (3072×1920 on 16" with terminal.integrated.fontSize = 13) Something in the range of 4-8 lines might be a decent compromise considering the original request that led to the change ()
I think the best approach would be to just have a default of let's say 4 lines, but also a setting that controls this, and/or as I mentioned, arguments to the command for being able to map multiple resize settings to different shortcuts:
I'd rather not add a setting for this as it's pretty obscure and would see hardly any usage. An additional complication here is I'd like to eventually remove the terminal resize commands since we now have the increase/decrease view size commands which weren't around when the terminal resize pane commands got . Seems like 4 rows should work for most people.
Can confirm this is fixed in Insiders. Thanks for the quick response