Without tmux, scroll once only 1/3 screen. In tmux, scroll once becomes 100x screens(pages). unacceptable. Can't review history because I cannot stop on specific page, scroll rate too fast there.

I think it's not hyper's issue. You might want to adjust your tmux "scrolling speed", it looks like your tmux will jump 5 lines for every scroll. Here's what I could find online on how to do it: https://stackoverflow.com/questions/36002866/configure-tmux-scroll-speed.
And this works for me:
bind -Tcopy-mode WheelUpPane send -N1 -X scroll-up
bind -Tcopy-mode WheelDownPane send -N1 -X scroll-down
Doesn’t work for me.
Inov Yomanovian notifications@github.com于2019年2月1日 周五19:27写道:
I think it's not hyper's issue. You might want to adjust your tmux
"scrolling speed", it looks like your tmux will jump 5 lines for every
scroll. Here's what I could find online on how to do it:
https://stackoverflow.com/questions/36002866/configure-tmux-scroll-speed.And this works for me:
bind -Tcopy-mode WheelUpPane send -N1 -X scroll-up
bind -Tcopy-mode WheelDownPane send -N1 -X scroll-down—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/zeit/hyper/issues/3338#issuecomment-459692717, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABAgI-dJH64OyAWG48SxWm36Vraw6DDOks5vJCSXgaJpZM4ZVpDq
.
I'm experiencing similar issues but am not finding much information online. Surely we aren't the only ones with scroll speed issues?
FWIW, native hyper without tmux doesn't play well with mouse and vim. I've seen information online supporting this. Seems to just be a bug in hyper or its terminal backend. Updating to Canary did not fix this. Ironically enough, when I incorporated tmux into my workflow, the mouse issues with vim and hyper went away. Except for this scroll speed issue...
Perhaps these issues with scroll speed in vim (outside of tmux) and scroll speed in tmux (no vim needed) are related??
Edit: Have a screencast showing the issue in vim/tmux with hyper.js. Screencast shows this working just fine in iterm2.

Edit2: Althought #95 was closed out as it was opened against Hyper 1.0/hterm, users reported in that thread that while their issue was fixed in Hyper 2.0/xterm, scroll speed was still an issue. I've verified the scroll speed issue is still present in Hyper 3.0 Canary as well.
I'm starting to believe it could be an issue down in xterm.js. I guess, based on my limited knowledge of hyper, that it's possible we're passing down bad values to xterm for the scroll wheel. But this seems unlikely.
Found the issue linked below and I'm wondering if OP's ticket can be reproduced in a different program that uses xterm.js. Since I can reproduce, I may try to figure that out.
When I tried these settings, they did not work for me:
bind -Tcopy-mode WheelUpPane send -N1 -X scroll-up
bind -Tcopy-mode WheelDownPane send -N1 -X scroll-down
I believe because I have tmux set up in vi mode, I needed different binds. I can confirm these tmux settings fixed my tmux scrollback issue:
bind-key -T copy-mode-vi WheelUpPane send -N1 -X scroll-up
bind-key -T copy-mode-vi WheelDownPane send -N1 -X scroll-down
This still has not fixed my scroll speed issue inside vim (whether inside tmux or not).
However, this ticket is specific to tmux so the vim behavior at this point is unrelated.
Edit: gif showing it broken with default 5 line scrolling and then it working as I expected with it set to 1.

So after looking into this more, adjusting tmux scroll speed via ~/.tmux.conf is not really solving the root of the issue. Now iterm2 and terminal.app scroll too slowly with the mouse wheel.
It does appear the issue is down in xterm.js, however, as the issue is present in ttyd, as well.
But why does xterm.js scroll so differently than every other application? I think we should open a ticket against xterm.js.
Gif below demonstrating hyper scrolling too fast next to iterm2 scrolling normal, then i adjust tmux.conf and hyper scrolls normal but iterm2 and terminal.app scroll too slow. lastly, ttyd scrolls exactly like hyper, so the issue seems to lie in xterm.js, not hyper itself.

I've discovered a workaround that works for me. Posting here in case it helps someone else.
Put this in .tmux.conf:
if "[[ ${TERM_PROGRAM} =~ Hyper || ${TERM_PROGRAM} =~ HyperTerm ]]" 'bind-key -T copy-mode-vi WheelUpPane send -N1 -X scroll-up'
if "[[ ${TERM_PROGRAM} =~ Hyper || ${TERM_PROGRAM} =~ HyperTerm ]]" 'bind-key -T copy-mode-vi WheelDownPane send -N1 -X scroll-down'
bind-key -T copy-mode-vi WheelUpPane send -N1 -X scroll-up
bind-key -T copy-mode-vi WheelDownPane send -N1 -X scroll-down
works for me on 3.0.1-canary.4 (canary) && tmux 2.9A.
N1 is excruciatingly slow. Try N3 etc etc
bind-key -T copy-mode-vi WheelUpPane send -N1 -X scroll-up bind-key -T copy-mode-vi WheelDownPane send -N1 -X scroll-downworks for me on 3.0.1-canary.4 (canary) && tmux 2.9A.
N1is excruciatingly slow. TryN3etc etc
work for me tmux 3.1c 👍
Seems to be working fine now
Tested on latest ci build and tmux 3.1c
Most helpful comment
works for me on 3.0.1-canary.4 (canary) && tmux 2.9A.
N1is excruciatingly slow. TryN3etc etc