Probably you cannot. xterm (and the programs which act like it) makes a distinction between mouse operations with/without the shift modifier:
- the unshifted operations can be programmed, i.e., an application can send an escape sequence telling xterm to send back escape sequences for each mouse click.
- the unshifted operations cannot be programmed in this way. They are left as-is.
tmux is not likely to be able to change this behavior. Further, the way the mouse buttons are used is (again, an old convention) in the way: one button acts to start a selection, another to extend the selection and the third to paste the selection. Some terminals may implement dragging if you hold down the extend-selection button.
But the wheel mouse is (really) much newer than the rest of the protocol, probably from the mid/late-1990s. In the mouse protocol, it sends fake button events, e.g., buttons 4 and 5. While a terminal could be implemented to extend a selection using the wheel mouse,
tmux has no way to control that—and it likely would be built-in/not-configurable. If you are not seeing the desired behavior already, you probably cannot get it.
The distinction with shift is very old, and not confined to mouse operations: on some platforms, the page-up and page-down keys are setup to scroll the terminal when the shift modifier is added, while the unshifted keys may be read from an application.
- Wheel mice (XTerm Control Sequences)
- Normal tracking mode (XTerm Control Sequences)
Default Key Bindings XTerm manual, e.g., the bindings for mouse-buttons
~Meta <Btn1Down>:select-start() \n\
~Meta <Btn1Motion>:select-extend() \n\
~Ctrl ~Meta <Btn2Up>:insert-selection(SELECT, CUT_BUFFER0) \n\
~Ctrl ~Meta <Btn3Down>:start-extend() \n\
~Meta <Btn3Motion>:select-extend() \n\