Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mouse scrolling in tmux 2.1 on OSX no longer auto-starts #145

Closed
victorhooi opened this issue Oct 19, 2015 · 82 comments
Closed

Mouse scrolling in tmux 2.1 on OSX no longer auto-starts #145

victorhooi opened this issue Oct 19, 2015 · 82 comments

Comments

@victorhooi
Copy link

@victorhooi victorhooi commented Oct 19, 2015

I have installed tmux via Homebrew on OSX.

I have just upgraded from tmux 2.0 to 2.1.

I read the changelog, which mentioned the mouse options changed, so my ~/.tmux.conf file now has:
``
set-option -g mouse on


Previously I was able to start scrolling immediately - that is, scrolling upwards would go into copy-mode automatically, and then if I scrolled back to the bottom it exited automatically.

However, apparently in 2.1 this feature was removed (although it wasn't mentioned in the changelog) - I read it here:

http://www.davidverhasselt.com/better-mouse-scrolling-in-tmux/

My question is - would it be possible to add the auto-start to scrolling, and auto-exit back in?

@victorhooi
Copy link
Author

@victorhooi victorhooi commented Oct 19, 2015

Also, I should mention that the workaround on that page:

bind -n WheelUpPane copy-mode

does not work for me - all it seems to do is break mouse scrolling, so that even if I try to enter in copy-mode, it doesn't even work there when this option is enabled.

@NHDaly
Copy link

@NHDaly NHDaly commented Oct 19, 2015

I've gotten it to work with this command (note the command is longer than the github preview box, so scroll sideways to see it all):

# Start copy mode when scrolling up and exit when scrolling down to bottom.
# The "#{mouse_any_flag}" check just sends scrolls to any program running that
# has mouse support (like vim).
bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'copy-mode -    e'"

I've created this plugin that wraps up the above command with an option to disable exiting copy-mode by scrolling down:
https://github.com/NHDaly/tmux-scroll-copy-mode

@apriendeau
Copy link

@apriendeau apriendeau commented Oct 19, 2015

@victorhooi @NHDaly 's plugin returns this to normal behavior for me.

@jlowgren
Copy link

@jlowgren jlowgren commented Oct 20, 2015

Having issues with this after upgrading to 2.1. Any hints on how to get the same behavior as before would be great.

@adamk33n3r
Copy link

@adamk33n3r adamk33n3r commented Oct 20, 2015

@jlowgren Very odd. It seems @NHDaly is no longer an account on github. He had a repository that had a plugin which brought back the behavior. Luckily I cloned the repo before this happened. I've pushed it up here: https://github.com/adamk33n3r/tmux-scroll-copy-mode

@NHDaly
Copy link

@NHDaly NHDaly commented Oct 20, 2015

Whoops! My account was temporarily closed because apparently "One of our
mostly harmless robots seems to think you are not a human." I emailed them and it's taken care of. https://twitter.com/Kimli/status/638760987487768576

But yep, hopefully that plugin will help, @jlowgren!

@mdibaiee
Copy link

@mdibaiee mdibaiee commented Oct 20, 2015

Same problem here, @NHDaly's plugin works like a charm. Probably we can get this merged to tmux?

@ThomasAdam
Copy link
Contributor

@ThomasAdam ThomasAdam commented Oct 20, 2015

No,

There's nothing to merge in here. Tmux is meant to be scriptable. Enjoy!

Thomas Adam

On 20 October 2015 at 21:19, Mahdi Dibaiee notifications@github.com wrote:

Same problem here, @NHDaly https://github.com/NHDaly's plugin works
like a charm. Probably we can get this merged to tmux?


Reply to this email directly or view it on GitHub
#145 (comment).

@ThomasAdam ThomasAdam closed this Oct 20, 2015
@victorhooi
Copy link
Author

@victorhooi victorhooi commented Oct 20, 2015

I understand that it's scriptable - and that is awesome.

However, it seems like a lot of people were quite used to, or preferred the old behaviour in Tmux 2.0 and before.

Is there any chance this could simply be added as an option?

Or are there technical or UI reasons why the new behaviour (needing to explicitly call Ctrl + B + ] to scroll) is superior? I'm assuming there was a reason for the change, just curious why.

@nicm
Copy link
Member

@nicm nicm commented Oct 20, 2015

@adamk33n3r
Copy link

@adamk33n3r adamk33n3r commented Oct 20, 2015

@nicm speaking of number of lines scrolled, is there a config option for that? I couldn't find anything on the subject.

@nicm
Copy link
Member

@nicm nicm commented Oct 20, 2015

No, I had something but nobody asked for it so it was dropped. I think this was it http://pastebin.ca/raw/3209063, it should still work.

@NHDaly
Copy link

@NHDaly NHDaly commented Oct 20, 2015

@nicm: I think the default key binding would be:

bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'copy-mode -e'"

Thanks for looking at this!

@nicm
Copy link
Member

@nicm nicm commented Oct 21, 2015

Yes this is reasonable, I've added it.

On Tue, Oct 20, 2015 at 04:20:58PM -0700, Nathan Daly wrote:

[1]@nicm: I think the default key binding would be:

bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M"
"if -Ft= '#{pane_in_mode}' 'send-keys -M' 'copy-mode -e'"

--
Reply to this email directly or [2]view it on GitHub.

Reverse link: [3]unknown

References

Visible links

  1. https://github.com/nicm
  2. #145 (comment)
  3. #145 (comment)
@victorhooi
Copy link
Author

@victorhooi victorhooi commented Oct 22, 2015

@NCIM @NHDaly Just to clarify - the above keybinding is only for entering copy mode, right?

As in, do we need a second one to exit out of copy-mode, when you scroll back down to the bottom? (I believe 2.0 did this).

@NHDaly
Copy link

@NHDaly NHDaly commented Oct 22, 2015

No, it's both -- the -e on copy-mode -e sets it to exit when scrolling
down to bottom.

On Wed, Oct 21, 2015 at 5:56 PM, Victor Hooi notifications@github.com
wrote:

@NCIM https://github.com/ncim @NHDaly https://github.com/NHDaly Just
to clarify - the above keybinding is only for entering copy mode, right?

As in, do we need a second one to exit out of copy-mode, when you scroll
back down to the bottom? (I believe 2.0 did this).


Reply to this email directly or view it on GitHub
#145 (comment).

sq3 pushed a commit to sq3/env that referenced this issue Oct 22, 2015
According to version tmux 2.1

CHANGES FROM 2.0 to 2.1 18 October 2015

Incompatible Changes
====================

* Mouse-mode has been rewritten.  There's now no longer options for:
	- mouse-resize-pane
	- mouse-select-pane
	- mouse-select-window
	- mode-mouse

  Instead there is just one option:  'mouse' which turns on mouse support
  entirely.
* 'default-terminal' is now a session option.  Furthermore, if this is set
  to 'screen-*' then emulate what screen does.  If italics are wanted, this
  can be set to 'tmux' but this is still new and not necessarily supported
  on all platforms with older ncurses installs.
* The c0-* options for rate-limiting have been removed.  Instead, a backoff
  approach is used.
  https://raw.githubusercontent.com/tmux/tmux/master/CHANGES

Fixing mouse mode with this
tmux/tmux#145 (comment)
@builtinnya
Copy link

@builtinnya builtinnya commented Oct 24, 2015

@NHDaly 's solution works for me. Thanks a lot!

bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'copy-mode -e'"
@milosivanovic
Copy link

@milosivanovic milosivanovic commented Oct 26, 2015

Am I missing something? I've added:

set -g mouse on
bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'copy-mode -e'"

to my .tmux.conf, and I am not able to get the old behaviour back. I'm running commit e95df0b, HEAD at this point.

@milosivanovic
Copy link

@milosivanovic milosivanovic commented Oct 26, 2015

Ah, sorry, I had a previous instance of tmux running which caused it to not use the updated settings even though I was starting a fresh instance of tmux.

With everything working right it seems like all that's missing is specifying how many lines to skip. Previously on my configuration it was 5, but now it's only skipping 1 line. Is this currently possible?

@milosivanovic
Copy link

@milosivanovic milosivanovic commented Oct 26, 2015

I've also noticed that with the proposed workaround, one scroll is required to enter copy mode, whereas before, the initial scroll entered copy mode and scrolled 5 lines in one go. Will this be possible to configure with the new version as well? I am just trying to get everything exactly back to the way it was before.

@milosivanovic
Copy link

@milosivanovic milosivanovic commented Oct 26, 2015

I was able to get the original functionality with a small change to @NHDaly's bind configuration. I kindly ask @nicm that you include this in the official default for backwards-compatibility's sake (replacing what @NHDaly had).

bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'copy-mode -e; send-keys -M'"

The difference is the addition of send-keys -M at the end.

There is one last difference I noticed, and that's if you left-click-and-hold inside the tmux session while in copy mode, it no longer highlights the character at the cursor, and when you let go, it no longer exits copy mode. You now have to highlight more than one character. I have become accustomed to exiting copy mode by just doing a single click, so it would be ideal to have this function the same as version 2.0 for backwards-compatibility reasons. If there is an argument against this then at least a way to configure it manually would be much appreciated.

@milosivanovic
Copy link

@milosivanovic milosivanovic commented Oct 26, 2015

I've unfortunately encountered another regression. I'm not sure if I should just open a new issue listing them all, since they all seem to be related to automatic mouse scrolling, which this issue addresses.

The latest regression stops users from scrolling the pane that the mouse is currently hovering over. Prior to version 2.1, with the help of mouse-select-pane, it was possible to hover over any pane of your choice and scroll up or down to automatically initiate copy mode without having to click into the pane (or select it using the keyboard.) You now have to select each pane manually before scrolling.

You can see all of these regressions impact one's productivity. I think it goes without question that if you, and I quote, specify:

Mouse-mode has been rewritten.  There's now no longer options for:
    - mouse-resize-pane
    - mouse-select-pane
    - mouse-select-window
    - mode-mouse

  Instead there is just one option:  'mouse' which turns on mouse support
  entirely.

(from https://raw.githubusercontent.com/tmux/tmux/e95df0bc3982ef7367b48236837069013642be14/CHANGES)

then this new mode 'mouse' is, by definition, meant to do exactly the same as all of the previous options had done by default, which it is not. This breaks all common sense rules about backwards compatibility. It goes without saying that all of these issues need to be addressed and resolved to fully restore backwards compatibility with earlier versions. The given reason that initiated all of these changes ("whether it should scroll 1 line or 3 lines or 10
lines or just inside copy mode or outside") does not in any way make it acceptable to break backwards compatibility. You should instead be providing defaults that precisely match previous versions, which are then overridden as-needed by individual users.

If you would like me to open a new issue listing mouse-related regressions, I'm more than happy to do so.

@milosivanovic
Copy link

@milosivanovic milosivanovic commented Oct 26, 2015

I managed to find the required configuration to allow selecting the pane with the mouse wheel, thanks to Thomas Sattler (https://groups.google.com/d/msg/tmux-users/TRwPgEOVqho/Ck_oth_SDgAJ):

bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'select-pane -t=; copy-mode -e; send-keys -M'"
bind -n WheelDownPane select-pane -t= \; send-keys -M

This should be the built-in default.

I was not able to find the configuration to enter and exit copy mode on single click, which is the only outstanding regression that I am presently aware of. If you single-click in the pane in which copy mode is currently enabled, scrolling to the bottom (after doing this) will not exit copy mode as otherwise expected.

wyattjoh added a commit to wyattjoh/dotfiles that referenced this issue Oct 26, 2015
@brentvatne
Copy link

@brentvatne brentvatne commented Oct 27, 2015

@milosivanovic - that fix works great 😄 agreed, this should be the default.

@NHDaly
Copy link

@NHDaly NHDaly commented Mar 29, 2016

The latest version of my plugin NHDaly/tmux-scroll-copy-mode has an option to disable the scroll-wheel while in alternate screen mode: NHDaly/tmux-better-mouse-mode#6.

It's off by default but you can turn it on like this:
set -g @prevent-scroll-for-fullscreen-alternate-buffer 'on'

It shouldn't be too hard to modify that option to instead just send the arrow keys instead of sending nothing, but I haven't gotten around to it yet. Feel free to send me a pull request or open an issue! :)

@giddie
Copy link

@giddie giddie commented Mar 30, 2016

Thanks @NHDaly. I've already enabled that option in your plugin. I'll take a look at the code to see if I can modify it to send arrow keys. Pull request coming up :)

nurey added a commit to nurey/dotfiles that referenced this issue Apr 7, 2016
kkwak pushed a commit to kkwak/dotfiles that referenced this issue Apr 13, 2016
@lpender
Copy link

@lpender lpender commented Apr 29, 2016

I really enjoy tmux but how is that the talented developers behind it do not respect semver?

  1. MAJOR version when you make incompatible API changes,

This change to the API should have been tmux 3.0, not 2.1, or they should have supported-but-deprecated the previous API.

@nicm
Copy link
Member

@nicm nicm commented Apr 29, 2016

I disagree - as the founder and Head Bossy Boots of the newly created Campaign For Version Numbering That I Like, If You Please, Thank You Very Much (CFVNTILIYPTYVM), I contend that the correct way to number releases is 1, 2, 3, 3.1, 95, 98, 2000, XP, Vista, 7, 8, 8.1, 10. I shall be contacting Mozilla, Google and Apple to demand that they comply with this - clearly superior - scheme forthwith. Naturally I expect they will comply, at which point I plan to release tmux Vista Snow Lion 2016.

@lpender
Copy link

@lpender lpender commented Apr 29, 2016

Lol

Might as well make it 3016 and future proof it

kchien added a commit to kchien/dotfiles that referenced this issue May 4, 2016
@dave-kennedy
Copy link

@dave-kennedy dave-kennedy commented May 4, 2016

I use st and openbox, and for some reason @milosivanovic's bindings cause the terminal to close. The following accomplishes what I want: scroll pane under cursor on mouse up and enter copy mode:

set-option -g mouse on
bind-key -T root WheelUpPane select-pane -t =\; copy-mode -e\; send-keys -M
dchabot pushed a commit to dchabot/dotfiles that referenced this issue May 9, 2016
netj added a commit to netj/dotfiles that referenced this issue Jun 8, 2016
@geoherna
Copy link

@geoherna geoherna commented Jun 27, 2016

@NHDaly's solution worked perfectly for using scroll to enter copy mode. Excellent work.

soulflyer added a commit to soulflyer/tm that referenced this issue Jul 11, 2016
@chellberg
Copy link

@chellberg chellberg commented Sep 14, 2016

The above solutions worked for me for a while, and then something somewhere updated (either os x or iterm or tmux) and then none of them worked.

Fix:

set-option -g mouse on (I don't appear to need the Bindwheel stuff now)
brew reinstall --HEAD tmux

@whitlockjc
Copy link

@whitlockjc whitlockjc commented Sep 14, 2016

I've come to the conclusion that the issue is Terminal.app. I'm on OS X 10.10.x and with Terminal.app, mouse mode of any kind fails to work. Using iTerm.app, the same configuration works as expected. I hear newer versions of Terminal.app have mouse reporting but the one I'm using, and likely versions before it, do not.

@jeremyjjbrown
Copy link

@jeremyjjbrown jeremyjjbrown commented Sep 22, 2016

@chellberg Your solution worked for me as well. Even in vim with Nerdtree and split tabs it is all scrolling normally. Thanks.

anderkonzen added a commit to anderkonzen/dotfiles that referenced this issue Oct 28, 2016
anderkonzen added a commit to anderkonzen/dotfiles that referenced this issue Oct 28, 2016
@tommyjcarpenter
Copy link

@tommyjcarpenter tommyjcarpenter commented Dec 18, 2016

I'm using

bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'select-pane -t=; copy-mode -e; send-keys -M'"
bind -n WheelDownPane select-pane -t= \; send-keys -M

but when I start scrolling, it always scrolls the leftmost pane, and not whatever pane I currently have selected. How do I configure it to scroll the pane I'm in?

I have also tried

set-option -g mouse on
bind-key -T root WheelUpPane select-pane -t =\; copy-mode -e\; send-keys -M

but I have the same problem. Scrolling the trackpad immediately switches back to the left "first" pane and scrolls there.

rcarraretto added a commit to rcarraretto/dotfiles that referenced this issue Aug 5, 2017
@ar0ra1
Copy link

@ar0ra1 ar0ra1 commented Oct 11, 2017

I tried all, the scrolling works fine until i start use vi
it no longer scrolls in vi
any solution to that ?

@leehambley
Copy link

@leehambley leehambley commented Oct 11, 2017

@ar0ra1
Copy link

@ar0ra1 ar0ra1 commented Oct 11, 2017

@leehambley
if i remove the binding and set option from the tmux.conf
i can scroll in vim
with or without tmux, it works fine.

but not when using set -g mouse on

@ar0ra1
Copy link

@ar0ra1 ar0ra1 commented Oct 12, 2017

Found the solution,
For tmux 2.1 +
in tmux.conf

set -g mouse on

And in .vimrc

set mouse=a

@tommyjcarpenter
Copy link

@tommyjcarpenter tommyjcarpenter commented Oct 12, 2017

@ar0ra1 solution seems to work for me, with the caveat that, in TMUX, scrolling the mouse scrolls up the commands as if you pressed the up arrow key many times. It does not automatically enter the "ctrl-b [" mode where you scroll up in the terminal itself. I was hoping for a way for mouse to automatically enter the "ctrl-b [" mode.

However @ar0ra1's solution definitely fixes my vim so that it has the behavior I desire where it scrolls in the terminal itself (like up in the source file).

@ar0ra1
Copy link

@ar0ra1 ar0ra1 commented Oct 12, 2017

@tommyjcarpenter it actually requires you to scroll two times, first time to initiate C-b [
then second time is your natural scrolling

the problem I next faced was eventually of the default copy paste operation, since tmux doesn't actually copy it to the OS's clipboards, instead to its copy buffer.

But then, holding down the shift key for selecting and right clicking fixed that.

@lock
Copy link

@lock lock bot commented Feb 15, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Feb 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.