4 ms·

For things like altering split-pane layouts, mouse remains king for both quickly & precisely adjusting width and height - at the same time, no less. Quickly mov

For things like altering split-pane layouts, mouse remains king for both quickly & precisely adjusting width and height - at the same time, no less. Quickly moving focus to 1 random pane out of 6+ is also a single input, whereas with keys it can be up to ~(total number of panes - 1). It's also a single config option to enable all mouse functionality, whereas setting up keybindings do just the resizing takes several lines.

laumars 7y ago
> For things like altering split-pane layouts, mouse remains king for both quickly & precisely adjusting width and height - at the same time, no less. Quickly moving focus to 1 random pane out of 6+ is also a single input, whereas with keys it can be up to ~(total number of panes - 1). You're not taking into account moving your hands from the keyboard and to the mouse, shacking it to find which where and on which screen your mouse cursor is located, and then putting your hands back on the keyboard after the resize. However what we're really arguing about is negligible micro-optimisations anyway so it's a little silly to say one is faster or slower than another. :) > It's also a single config option to enable all mouse functionality, whereas setting up keybindings do just the resizing takes several lines. Keybindings for selecting and resizing panes are already defined in tmux's defaults. You don't need to configure nor enable it. However it is something you'd need to look up, commit to memory, then muscle memory after. Which I guess creates enough of an hurdle that many people haven't bothered to jump.