Here is the situation: When resizing a tmux pane, the history of the pane is reflowed with width changes. This consumes a lot of CPU when the panes affected have a lot of history (with long lines).

This can be further compounded by the fact that a resizing action can affect any number of panes, e.g. a layout like this which is rather common in the layouts I end up building:

┌────┐
├─┬──┤
│ ├──┤
│ ├──┤
└─┴──┘

When you adjust the vertical division on the bottom there, you are horizontally resizing 4 panes, and if they all have a bunch of history, then up to [max buffer lines] * [no. of panes] lines would be reflowed when resizing that. I suppose if most of the lines are not very long, it wont be much overhead, but I've recently discovered that this can make resizing extremely slow for certain types of log output.

Now I like to have lots of history buffer, you know, just in case a long running command I run turns out to be an important one, so I'd been thinking about increasing my history buffer line limit from 100k to an even higher value, but it seems like it might be a bad idea given this situation.

So what I would like to consider is the possibility of having lazy reflow: Only reflow history lines into current width when we scroll up to them, instead of immediately upon resize.

Failing that, perhaps the reflow could at least be deferred until the initial scroll up in copy mode, or failing that, upon entering copy mode. The main point is that as things are now, resizing a particular column divider potentially causes a lot of immediate computation, and it should be deferrable, and limiting buffer size as a tradeoff is unappealing.