OK, I'll just disable mouse-select-pane then...
Best,
Mika
On Thu, Sep 9, 2010 at 09:55, Nicholas Marriott
wrote:
> On Thu, Sep 09, 2010 at 09:38:46AM +0200, Mika Fischer wrote:
>> On Thu, Sep 9, 2010 at 09:33, Nicholas Marriott
>> wrote:
>> > i think gnome-terminal sends up/down (^[[A/^[[B) f
On Thu, Sep 09, 2010 at 09:38:46AM +0200, Mika Fischer wrote:
> On Thu, Sep 9, 2010 at 09:33, Nicholas Marriott
> wrote:
> > i think gnome-terminal sends up/down (^[[A/^[[B) for the scroll wheel
> > when not in mouse mode, this obviously won't work when a program has
> > captured the mouse instead
On Thu, Sep 9, 2010 at 09:33, Nicholas Marriott
wrote:
> i think gnome-terminal sends up/down (^[[A/^[[B) for the scroll wheel
> when not in mouse mode, this obviously won't work when a program has
> captured the mouse instead (eg when mouse-select-pane is on and >1 pane
> is visible, or when anot
On Thu, Sep 09, 2010 at 09:29:29AM +0200, Mika Fischer wrote:
> On Wed, Sep 8, 2010 at 22:58, Nicholas Marriott
> wrote:
> > i don't know where the ^[[A and ^[[B are coming from, it looks like your
> > terminal is sending up and down key presses for the scroll
> > wheel. perhaps it only does it in
On Wed, Sep 8, 2010 at 22:58, Nicholas Marriott
wrote:
> i don't know where the ^[[A and ^[[B are coming from, it looks like your
> terminal is sending up and down key presses for the scroll
> wheel. perhaps it only does it in cup mode, try "tput smcup" outside and
> see if you get them (without d
i am getting everything perfectly fine in putty and xterm:
when i do echo \\033[?1000h i get identical behaviour inside tmux with
and without mouse-select-pane and outside tmux. that is, i get ^[[M`!!
for scroll up and ^[[Ma!! for scroll down
without doing the echo, i get no output at all and the
^[[A and ^[[B are up and down and tmux won't generate them for scroll
events so the terminal must be doing it for one or another mode
when mouse-select-pane is on and there are panes, the terminal should
always be in mouse input mode, when mouse-select-pane is off it should
only be in mouse input
The output is the same as with mouse-select-pane on...
Maybe the printf changes something that makes the two cases behave the
same. Because after the printf, the scroll events don't cycle through
the command history in bash anymore, even when mouse-select-pane is
off. Before the printf, the wheel
what output do you get with it off doing the same test?
On Fri, Sep 03, 2010 at 03:24:32PM +0200, Mika Fischer wrote:
> No, the problem only happens when mouse-select-pane is on. If it's
> off, everything works as it should.
>
> On Fri, Sep 3, 2010 at 15:17, Nicholas Marriott
> wrote:
> > yes,
No, the problem only happens when mouse-select-pane is on. If it's
off, everything works as it should.
On Fri, Sep 3, 2010 at 15:17, Nicholas Marriott
wrote:
> yes, probably, do you get the same with mouse-select-pane on and off?
>
>
> On Fri, Sep 03, 2010 at 03:09:19PM +0200, Mika Fischer wrote:
yes, probably, do you get the same with mouse-select-pane on and off?
On Fri, Sep 03, 2010 at 03:09:19PM +0200, Mika Fischer wrote:
> But the scrolling works fine if there's only one pane or when
> mouse-select-pane is off. So there must be something different when
> using multiple panes in conju
But the scrolling works fine if there's only one pane or when
mouse-select-pane is off. So there must be something different when
using multiple panes in conjunction with mouse-select-pane, right?
On Fri, Sep 3, 2010 at 15:06, Nicholas Marriott
wrote:
> The first character after the [M is the but
The first character after the [M is the buttons and tmux is outputting
the same thing in all cases, so the problem is less or whatever. Maybe
it only listens for mouse clicks when TERM=xterm or something silly like
that.
On Fri, Sep 03, 2010 at 02:51:12PM +0200, Florian CROUZAT wrote:
>
> On 3 s
For me (gnome-terminal, bash, tmux 1.3):
Without tmux:
scroll-up: ^[[MaXX
scroll-down: ^[[M`XX
click: ^[[M XX^[[M#XX (button down & button up events)
(where XX changes with the mouse position)
tmux one pane:
exactly the same
tmux multiple panes:
exactly the same
Not sure what to make
On 3 sept. 2010, at 14:38, Nicholas Marriott wrote:
> what happens if you do printf "\033[?1000h" then cat and scroll the
> wheel, inside and outside tmux?
With mouse-select-pane on (tmux1.3+Terminal.app+mouseterm: plugin to give
Terminal.app mouse support)
Outside tmux:
scroll-up: ^[[
On Fri, Sep 03, 2010 at 02:32:11PM +0200, Mika Fischer wrote:
> On Fri, Sep 3, 2010 at 14:14, Nicholas Marriott
> wrote:
> > either tmux captures the mouse or the terminal handles it, one or the
> > other
>
> But that does not seem to happen in this case. Either the event gets
> lost or it's tran
On Fri, Sep 3, 2010 at 14:14, Nicholas Marriott
wrote:
> either tmux captures the mouse or the terminal handles it, one or the
> other
But that does not seem to happen in this case. Either the event gets
lost or it's translated somehow so that the application does not react
to it appropriately.
either tmux captures the mouse or the terminal handles it, one or the
other
most terminals allow you to hold down shift to override application use
of the mouse but i don't know if it works for the scroll wheel
On Fri, Sep 03, 2010 at 01:27:27PM +0200, Mika Fischer wrote:
> With tmux 1.3, scroll
On 3 sept. 2010, at 13:27, Mika Fischer wrote:
> With tmux 1.3, scrolling does not emit strange things, but it still
> doesn't work. Nothing happens when scrolling in a split pane.
>
> Strangely, everything works fine in vim in a split pane (both with 1.1
> and 1.3). The problem happens with les
With tmux 1.3, scrolling does not emit strange things, but it still
doesn't work. Nothing happens when scrolling in a split pane.
Strangely, everything works fine in vim in a split pane (both with 1.1
and 1.3). The problem happens with less and bash...
Best,
Mika
On Fri, Sep 3, 2010 at 13:07, M
20 matches
Mail list logo
