Discussion:
Mouse scroll in Less
Paul Gideon Dann
2013-11-18 12:39:22 UTC
Permalink
Hello all,

I've spent so long trying to find a solution to this that I decided to ask the experts, in the
hope that a solution does in fact exist.

In my .tmux file, I have (of relevance):

set -g mouse-select-pane on
set -g mouse-resize-pane on
set -g mouse-select-window on
setw -g mode-mouse on

If none of these options are present, tmux will pass through mouse wheel scroll events as
emulated arrow-key events (as determined by "cat -v"):

^[[A^[[A^[[A^[[B^[[B^[[B

However, if one or more of these options is enabled, tmux enters a "mouse capture" mode,
and doesn't emulate the mouse scroll wheel in this way, and nothing at all is passed to "cat
-v". This all seems well and good, and certain applications (e.g. Vim) work brilliantly,
because they are themselves mouse-aware, and the world is a wonderful place.

However, when it comes to reading man pages, git logs, or indeed anything that uses a
pager (mostly "less", by default), I do not have the ability to scroll with the mouse, and I
REALLY miss this (mainly for man pages). Less pops up, and scrolling the mouse simply
enters copy-mode (if mode-mouse is on), or nothing at all happens (if mode-mouse is off or
copy-mode).

Naturally, this is because tmux is no longer forwarding on an emulated three-up or three-
down sequence that makes the scroll wheel act like the user is pressing the up and down
arrows. However, I've had no luck at all finding a way to make "less" mouse-aware in order
to make mouse scrolling work correctly in tmux.

Interestingly, outside of tmux, Konsole doesn't perform any arrow-key emulation on scroll:
"cat -v" shows nothing when I scroll the mouse, but the scrollbuffer scrolls up (as expected).
This is very similar behaviour to tmux. However, when "less" is used directly in Konsole, I'm
able to use the mouse to scroll up and down. I'm not entirely sure what kind of magic is
going on there, but it gives me hope that the same behaviour might be possible in tmux.

Any thoughts / help would be greatly appreciated.

Paul
Nicholas Marriott
2013-11-18 12:44:27 UTC
Permalink
Probably it guesses you want the mouse to send arrow keys when the
terminal is in alternate screen, try doing

tput smcup

and see if that makes konsole send them to cat -v.

tmux could do this but then mouse wouldn't work for copy mode in any
full-screen applications.
Post by Paul Gideon Dann
Hello all,
I've spent so long trying to find a solution to this that I decided to ask
the experts, in the hope that a solution does in fact exist.
set -g mouse-select-pane on
set -g mouse-resize-pane on
set -g mouse-select-window on
setw -g mode-mouse on
If none of these options are present, tmux will pass through mouse wheel
^[[A^[[A^[[A^[[B^[[B^[[B
However, if one or more of these options is enabled, tmux enters a "mouse
capture" mode, and doesn't emulate the mouse scroll wheel in this way, and
nothing at all is passed to "cat -v". This all seems well and good, and
certain applications (e.g. Vim) work brilliantly, because they are
themselves mouse-aware, and the world is a wonderful place.
However, when it comes to reading man pages, git logs, or indeed anything
that uses a pager (mostly "less", by default), I do not have the ability
to scroll with the mouse, and I REALLY miss this (mainly for man pages).
Less pops up, and scrolling the mouse simply enters copy-mode (if
mode-mouse is on), or nothing at all happens (if mode-mouse is off or
copy-mode).
Naturally, this is because tmux is no longer forwarding on an emulated
three-up or three-down sequence that makes the scroll wheel act like the
user is pressing the up and down arrows. However, I've had no luck at all
finding a way to make "less" mouse-aware in order to make mouse scrolling
work correctly in tmux.
Interestingly, outside of tmux, Konsole doesn't perform any arrow-key
emulation on scroll: "cat -v" shows nothing when I scroll the mouse, but
the scrollbuffer scrolls up (as expected). This is very similar behaviour
to tmux. However, when "less" is used directly in Konsole, I'm able to use
the mouse to scroll up and down. I'm not entirely sure what kind of magic
is going on there, but it gives me hope that the same behaviour might be
possible in tmux.
Any thoughts / help would be greatly appreciated.
Paul
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
https://lists.sourceforge.net/lists/listinfo/tmux-users
Paul Gideon Dann
2013-11-18 13:45:10 UTC
Permalink
Post by Nicholas Marriott
Probably it guesses you want the mouse to send arrow keys when the
terminal is in alternate screen, try doing
tput smcup
and see if that makes konsole send them to cat -v.
tmux could do this but then mouse wouldn't work for copy mode in any
full-screen applications.
The behaviour in Konsole seems to be: if the buffer has never scrolled (i.e. there is no
scrollback history), arrow keys are sent on mouse scroll. If there is a scrollback history,
arrow keys are *not* sent, and instead the window scrolls through the history.

When Konsole is in the alternate buffer, scrolling is disabled, so it locks into the mode in
which it sends arrow keys on scroll events.

Could you explain a little more about why this would break copy-mode for full-screen
applications in tmux?

Paul
Nicholas Marriott
2013-11-18 13:56:41 UTC
Permalink
tmux can either send arrow keys for the mouse wheel or it can enter copy
mode, not both. If it decides using whatever heuristic that it should
send arrow keys, then that stops it entering copy mode.

If there is no history at all then that's irrelevant and it'd work fine.
Post by Paul Gideon Dann
Post by Nicholas Marriott
Probably it guesses you want the mouse to send arrow keys when the
terminal is in alternate screen, try doing
tput smcup
and see if that makes konsole send them to cat -v.
tmux could do this but then mouse wouldn't work for copy mode in any
full-screen applications.
The behaviour in Konsole seems to be: if the buffer has never scrolled
(i.e. there is no scrollback history), arrow keys are sent on mouse
scroll. If there is a scrollback history, arrow keys are *not* sent, and
instead the window scrolls through the history.
When Konsole is in the alternate buffer, scrolling is disabled, so it
locks into the mode in which it sends arrow keys on scroll events.
Could you explain a little more about why this would break copy-mode for
full-screen applications in tmux?
Paul
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
https://lists.sourceforge.net/lists/listinfo/tmux-users
Paul Gideon Dann
2013-11-18 14:12:09 UTC
Permalink
Post by Nicholas Marriott
tmux can either send arrow keys for the mouse wheel or it can enter copy
mode, not both. If it decides using whatever heuristic that it should
send arrow keys, then that stops it entering copy mode.
If there is no history at all then that's irrelevant and it'd work fine.
Excellent: it's precisely when there is no history that we want this to happen, so it
seems there's no problem. In the case of "less", the alternate buffer is opened,
there is no history, and arrow keys are sent instead of entering copy-mode.
Naturally, text can still be copied with click+drag.

I'm not sure if it's standard behaviour for the alternate buffer to have no
scrollback history? This seems to be what Konsole does, as I mentioned, and so
arrow keys continue to be sent even as the man page is scrolled down.

How feasible is this to implement?

Paul
Nicholas Marriott
2013-11-18 15:35:20 UTC
Permalink
Lines are not added to history in alternate screen but in tmux existing
history is still available. But I don't think it is a big issue for the
scroll wheel not to enter copy mode in alternate screen mode.
Post by Paul Gideon Dann
Post by Nicholas Marriott
tmux can either send arrow keys for the mouse wheel or it can enter copy
mode, not both. If it decides using whatever heuristic that it should
send arrow keys, then that stops it entering copy mode.
If there is no history at all then that's irrelevant and it'd work fine.
Excellent: it's precisely when there is no history that we want this to
happen, so it seems there's no problem. In the case of "less", the
alternate buffer is opened, there is no history, and arrow keys are sent
instead of entering copy-mode. Naturally, text can still be copied with
click+drag.
I'm not sure if it's standard behaviour for the alternate buffer to have
no scrollback history? This seems to be what Konsole does, as I mentioned,
and so arrow keys continue to be sent even as the man page is scrolled
down.
How feasible is this to implement?
Paul
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
https://lists.sourceforge.net/lists/listinfo/tmux-users
Paul Gideon Dann
2013-11-18 15:54:59 UTC
Permalink
Post by Nicholas Marriott
Lines are not added to history in alternate screen but in tmux existing
history is still available. But I don't think it is a big issue for the
scroll wheel not to enter copy mode in alternate screen mode.
Oh yes; I see that if I enter copy-mode in Vim, I can scroll back to the console before Vim
was invoked. In my opinion, this actually feels a little confusing. It's never really occurred
to me that I might be able to scroll back, because in my head when I enter a new buffer,
the old one is hidden away behind the current buffer. To get back to it, I would always do
":sh" in Vim to return to the primary buffer and enter copy-mode there, then return to Vim.
Similarly for man/less, although it would mean actually exiting. Konsole certainly doesn't
allow me to scroll back until I leave the alternate buffer.

So I actually think implementing this behaviour in the alternate buffer would provide a
double-pronged element-of-least-surprise advantage:

1) It supports the concept that the primary buffer is hidden away behind the alternate
buffer, like a pop-up window, and therefore temporarily inaccessible.

2) It makes it possible for mouse scrolling in "man", "less", and others "just work" in the
way they do outside of term. (Or at least I assume terminals other than Konsole have this
behaviour too.)

Paul
Nicholas Marriott
2013-11-19 00:03:58 UTC
Permalink
As far as I'm aware konsole is the only one that does this. Possibly
gnome-terminal, certainly not xterm which is pretty much the standard
terminal now.

So I'd say it's more unexpected than expected. Still, I don't see any
harm in it - all the mouse stuff in tmux defaults to off anyway.

It would be better to do this without adding a new option though.
Post by Paul Gideon Dann
Post by Nicholas Marriott
Lines are not added to history in alternate screen but in tmux existing
history is still available. But I don't think it is a big issue for the
scroll wheel not to enter copy mode in alternate screen mode.
Oh yes; I see that if I enter copy-mode in Vim, I can scroll back to the
console before Vim was invoked. In my opinion, this actually feels a
little confusing. It's never really occurred to me that I might be able to
scroll back, because in my head when I enter a new buffer, the old one is
hidden away behind the current buffer. To get back to it, I would always
do ":sh" in Vim to return to the primary buffer and enter copy-mode there,
then return to Vim. Similarly for man/less, although it would mean
actually exiting. Konsole certainly doesn't allow me to scroll back until
I leave the alternate buffer.
So I actually think implementing this behaviour in the alternate buffer
1) It supports the concept that the primary buffer is hidden away behind
the alternate buffer, like a pop-up window, and therefore temporarily
inaccessible.
2) It makes it possible for mouse scrolling in "man", "less", and others
"just work" in the way they do outside of term. (Or at least I assume
terminals other than Konsole have this behaviour too.)
Paul
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
https://lists.sourceforge.net/lists/listinfo/tmux-users
Paul Gideon Dann
2013-11-19 10:02:38 UTC
Permalink
Post by Nicholas Marriott
As far as I'm aware konsole is the only one that does this. Possibly
gnome-terminal, certainly not xterm which is pretty much the standard
terminal now.
So I'd say it's more unexpected than expected. Still, I don't see any
harm in it - all the mouse stuff in tmux defaults to off anyway.
Ah, well I think that depends on your perspective. I suppose you *could* argue that the
least surprising thing is to do what everyone else does. However, I'd prefer to consider
the least surprising behaviour for someone who enters "man tmux" and just wants to scroll
the man page. What are the odds they actually want to scroll beyond the man page buffer
to the stuff that happened before?
Post by Nicholas Marriott
It would be better to do this without adding a new option though.
Yeah, I don't think it'll need an option. It seems unlikely that this new behaviour would get
in the way for anyone, particularly.

Is there a place I should formally submit this feature request?

Paul
Nicholas Marriott
2013-11-19 14:23:44 UTC
Permalink
I'll put it on the todo list.
Post by Nicholas Marriott
As far as I'm aware konsole is the only one that does this. Possibly
gnome-terminal, certainly not xterm which is pretty much the standard
terminal now.
So I'd say it's more unexpected than expected. Still, I don't see any
harm in it - all the mouse stuff in tmux defaults to off anyway.
Ah, well I think that depends on your perspective. I suppose you *could*
argue that the least surprising thing is to do what everyone else does.
However, I'd prefer to consider the least surprising behaviour for someone
who enters "man tmux" and just wants to scroll the man page. What are the
odds they actually want to scroll beyond the man page buffer to the stuff
that happened before?
Post by Nicholas Marriott
It would be better to do this without adding a new option though.
Yeah, I don't think it'll need an option. It seems unlikely that this new
behaviour would get in the way for anyone, particularly.
Is there a place I should formally submit this feature request?
Paul
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
https://lists.sourceforge.net/lists/listinfo/tmux-users
Paul Gideon Dann
2013-12-10 11:58:27 UTC
Permalink
I'm just wondering if the todo list is somewhere public, or is it a private
todo list? I'm keen to make sure it doesn't get buried. If it's unlikely
to get looked at soon, I might be able to find some time to look
implementing it myself, if you could point me in the right direction in the
codebase, but naturally I expect you could implement this faster. Thanks
for your work on tmux; all of it is very appreciated.

Paul
Post by Nicholas Marriott
I'll put it on the todo list.
Post by Nicholas Marriott
As far as I'm aware konsole is the only one that does this. Possibly
gnome-terminal, certainly not xterm which is pretty much the
standard
Post by Nicholas Marriott
terminal now.
So I'd say it's more unexpected than expected. Still, I don't see
any
Post by Nicholas Marriott
harm in it - all the mouse stuff in tmux defaults to off anyway.
Ah, well I think that depends on your perspective. I suppose you
*could*
argue that the least surprising thing is to do what everyone else
does.
However, I'd prefer to consider the least surprising behaviour for
someone
who enters "man tmux" and just wants to scroll the man page. What are
the
odds they actually want to scroll beyond the man page buffer to the
stuff
that happened before?
Post by Nicholas Marriott
It would be better to do this without adding a new option though.
Yeah, I don't think it'll need an option. It seems unlikely that this
new
behaviour would get in the way for anyone, particularly.
Is there a place I should formally submit this feature request?
Paul
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up
now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
https://lists.sourceforge.net/lists/listinfo/tmux-users
Nicholas Marriott
2013-12-10 12:10:31 UTC
Permalink
It's TODO file in git
Post by Paul Gideon Dann
I'm just wondering if the todo list is somewhere public, or is it a
private todo list?* I'm keen to make sure it doesn't get buried.* If it's
unlikely to get looked at soon, I might be able to find some time to look
implementing it myself, if you could point me in the right direction in
the codebase, but naturally I expect you could implement this faster.*
Thanks for your work on tmux; all of it is very appreciated.
Paul
On 19 November 2013 14:23, Nicholas Marriott
I'll put it on the todo list.
* *> As far as I'm aware konsole is the only one that does this.
Possibly
* *> gnome-terminal, certainly not xterm which is pretty much the
standard
* *> terminal now.
* *>
* *> So I'd say it's more unexpected than expected. Still, I don't see
any
* *> harm in it - all the mouse stuff in tmux defaults to off anyway.
* *Ah, well I think that depends on your perspective. I suppose you
*could*
* *argue that the least surprising thing is to do what everyone else
does.
* *However, I'd prefer to consider the least surprising behaviour for
someone
* *who enters "man tmux" and just wants to scroll the man page. What
are the
* *odds they actually want to scroll beyond the man page buffer to the
stuff
* *that happened before?
* *> It would be better to do this without adding a new option though.
* *Yeah, I don't think it'll need an option. It seems unlikely that
this new
* *behaviour would get in the way for anyone, particularly.
* *Is there a place I should formally submit this feature request?
* *Paul
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech
innovation.
Intel(R) Software Adrenaline delivers strategic insight and
game-changing
conversations that shape the rapidly evolving mobile landscape. Sign
up now.
[2]http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
[4]https://lists.sourceforge.net/lists/listinfo/tmux-users
References
Visible links
2. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
4. https://lists.sourceforge.net/lists/listinfo/tmux-users
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
https://lists.sourceforge.net/lists/listinfo/tmux-users
Loading...