Hello, On Thu, Mar 21, 2019 at 06:58:58AM +0000, Nicholas Marriott wrote: > Thanks but we don't want to add an option for this. tmux has too many > options already and we're not adding any more obscure options that > hardly anyone will use and that need then need to keep forever, not to
My /etc/screenrc has this by default: # Do not use xterm's alternative window buffer, it breaks scrollback (see bug #61195) termcapinfo xterm*|xs ti@:te=\E[2J I can send an endless list of URL with people that complains they can't use scrollback and they would like it to work like screen or that are told to press shift before selecting with the mouse if they are using copy-mode to scrollback. The problem with tmux is that adding 'terminal-overrides ",xterm*:smcup@:rmcup@"' is not enough. Most of the answers tell people to add the terminal-override to fix their issue, but I followed those answers initially and all I got was inconsistent data in the scrollback buffer of the terminal. Now if I completely ignore the remote scrollback issue and I only focus on the mouse selection behavior: I either lose word-by-word selection with doubleclick+drag, or I have to press shift before doubleclick+drag or I lose the wheelup from trackball. Either way my workflow regress. So the other option I considered to make the common case of my workflow regress less compared to screen, is to leave the mouse selection to the terminal by default and use the copy-mode selection when I press shift+pageup. So I considered adding an option to simply invert the "shift" behavior with "mouse on", that would already go a long way to at least fix the mouse selection issue. Then it is still troublesome to scrollback a remote tmux nested on local tmux, but that's less of a common case than the word-by-word selection with doubeclick+drag that I don't intend to lose as a feature. > mention the fact that we don't want to be tied to trying to keep the > scrollback consistent which is next to impossible. I only tested it in a single environment, it may well be inconsistent behavior, but it seem to do what screen does so I don't see a big risk in that. > This is a one line change that should be easy for you to maintain > privately if you want it. True and I'm fine to keep running screen on newly provisioned systems (that has the added benefit that it avoids me also to sync /etc/tmux.conf to remap the prefix keys so I can keep using a single hand to switch windows). I just thought I wasn't the only one dealing with regressed workflow that can't be fixed with the current available options. Alternatively is there a way I can patch konsole to trick tmux into setting MODE_INSERT on the pane? I tried that too, but I didn't find a way to do that. I doubt such a trick even if feasible would the work also on remote tmux though. Thank you, Andrea -- You received this message because you are subscribed to the Google Groups "tmux-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
