tmux

On Wed, Sep 19, 2012 at 01:37:59PM +0400, Sergey Naumov wrote:
> Is it possible to enable native xterm mouse scrolling while in tmux?
> What I actually want is to use xterm mouse scrolling by default and
> use mouse in tmux-like way only when I have entered to copy-mode by
> keyboard shortcut.

Don't think so.

> And is it possible to place copy-mode indicator ([linenum/total
> lines]) to statusbar or at least remove in completely?

It's in the TODO file.

-- Thomas Adam

2012/9/19 Thomas Adam <thomas@...>:
> On Wed, Sep 19, 2012 at 01:37:59PM +0400, Sergey Naumov wrote:
>> Is it possible to enable native xterm mouse scrolling while in tmux?
>> What I actually want is to use xterm mouse scrolling by default and
>> use mouse in tmux-like way only when I have entered to copy-mode by
>> keyboard shortcut.
>
> Don't think so.

Moreover, tmux 1.6 doesn't allow to use mouse in programs, at least -
in midnight commander and mcedit - I can no longer scroll through a
file, select files etc. With GNU screen I can.
I have surfed a source code a bit and, as I understand, there is no
reference to terminal from window_choose_mouse(). Is there a way
to determine whether we are in copy mode while parsing keys in
tty_keys_next()? May be we can resend mouse sequences to terminal?
By the way, how shift+PgUp/PgDn scrolling works? Does tmux process
these sequences?

Thanks in advance,
Sergey Naumov.

On Wed, Sep 19, 2012 at 09:19:35PM +0400, Sergey Naumov wrote:
> 2012/9/19 Thomas Adam <thomas@...>:
> > On Wed, Sep 19, 2012 at 01:37:59PM +0400, Sergey Naumov wrote:
> >> Is it possible to enable native xterm mouse scrolling while in tmux?
> >> What I actually want is to use xterm mouse scrolling by default and
> >> use mouse in tmux-like way only when I have entered to copy-mode by
> >> keyboard shortcut.
> >
> > Don't think so.
> 
> Moreover, tmux 1.6 doesn't allow to use mouse in programs, at least -
> in midnight commander and mcedit - I can no longer scroll through a
> file, select files etc. With GNU screen I can.

Use tmux 1.7, which is git HEAD from master.

> I have surfed a source code a bit and, as I understand, there is no
> reference to terminal from window_choose_mouse(). Is there a way
> to determine whether we are in copy mode while parsing keys in
> tty_keys_next()? May be we can resend mouse sequences to terminal?
> By the way, how shift+PgUp/PgDn scrolling works? Does tmux process
> these sequences?

No, tmux does not process those sequences.

-- Thomas Adam

2012/9/19 Thomas Adam <thomas@...>:
> On Wed, Sep 19, 2012 at 09:19:35PM +0400, Sergey Naumov wrote:
>> 2012/9/19 Thomas Adam <thomas@...>:
>> > On Wed, Sep 19, 2012 at 01:37:59PM +0400, Sergey Naumov wrote:
>> >> Is it possible to enable native xterm mouse scrolling while in tmux?
>> >> What I actually want is to use xterm mouse scrolling by default and
>> >> use mouse in tmux-like way only when I have entered to copy-mode by
>> >> keyboard shortcut.
>> >
>> > Don't think so.
>>
>> Moreover, tmux 1.6 doesn't allow to use mouse in programs, at least -
>> in midnight commander and mcedit - I can no longer scroll through a
>> file, select files etc. With GNU screen I can.
>
> Use tmux 1.7, which is git HEAD from master.
>
Actually I can't do it with screen (my keyboard at work much better
than at home so at home it was so inconvenient that I thought that I
use mouse at work =) ).
But installing tmux-1.7 did not help. I've inserted some log_warnx()
to trace tmux reaction on mouse clicks and here it is:
server_client_check_mouse(): call functions under "is this a pane
selection?" comment
window_pane_mouse(): call input_mouse
input_mouse(): call nothing

It have to call call bufferevent_write() for mouse to work?

Thanks in advance,
Sergey Naumov.

On Sun, Sep 23, 2012 at 04:03:43PM +0400, Sergey Naumov wrote:
> 2012/9/19 Thomas Adam <thomas@...>:
> > On Wed, Sep 19, 2012 at 09:19:35PM +0400, Sergey Naumov wrote:
> >> 2012/9/19 Thomas Adam <thomas@...>:
> >> > On Wed, Sep 19, 2012 at 01:37:59PM +0400, Sergey Naumov wrote:
> >> >> Is it possible to enable native xterm mouse scrolling while in tmux?
> >> >> What I actually want is to use xterm mouse scrolling by default and
> >> >> use mouse in tmux-like way only when I have entered to copy-mode by
> >> >> keyboard shortcut.
> >> >
> >> > Don't think so.
> >>
> >> Moreover, tmux 1.6 doesn't allow to use mouse in programs, at least -
> >> in midnight commander and mcedit - I can no longer scroll through a
> >> file, select files etc. With GNU screen I can.
> >
> > Use tmux 1.7, which is git HEAD from master.
> >
> Actually I can't do it with screen (my keyboard at work much better
> than at home so at home it was so inconvenient that I thought that I
> use mouse at work =) ).

Run mc as:

mc -x

That does work for me.  You might also want to look at "-g" to mc as well,
depending on your terminal.

-- Thomas Adam

> Run mc as:
>
> mc -x

Thanks, it works!

By the way, I suggest you consider to make tmux scrolling to behave
like mcedit's one (at least optional): scroll first (preserving
relational cursor position) and if we are at the top, then move cursor
up. Imagine that you use terminal and want to scroll up. In most cases
you are at the bottom line and, currently, you have to scroll the
cursor to the top of the screen to actually start scrolling - not very
convenient, espesially if you have a window with many lines. Proposed
option will mimic the behavior of native xterm scrolling.

Sergey Naumov.

Thomas,

how do you think, is there a way to detect if we are in terminal or in
program that is running in terminal? May be by raw mode or something
else? Entering to scroll mode automatically by mouse wheel is very
convenient in terminal, but it breaks mouse behavior for terminal
programs. May be it is worth to detect if we are in terminal and only
then enter to copy mode?

Also, could you explain how to detect if there is a up/down space
outside visible area we can scroll to? I have surfed  the code a bit a
have tried screen->grid->hsize, because screen_resize_y() uses it to
check if there is some lines to pull to new lines, but without success
- when we a scrolling, gd->hsize==0. If we can check in
window_copy_mouse() that there is a space to scroll to, we can send
scroll_only==1 to window_copy_cursor_up().

Sergey Naumov.

On 23 September 2012 20:56, Sergey Naumov <sknaumov@...> wrote:
> Also, could you explain how to detect if there is a up/down space
> outside visible area we can scroll to? I have surfed  the code a bit a
> have tried screen->grid->hsize, because screen_resize_y() uses it to
> check if there is some lines to pull to new lines, but without success
> - when we a scrolling, gd->hsize==0. If we can check in
> window_copy_mouse() that there is a space to scroll to, we can send
> scroll_only==1 to window_copy_cursor_up().

If your aim is to get scrolling without affecting the position of the
cursor when you enter copy-mode, there's been a patch for this sent to
this list recently -- but it's still very much in review.

-- Thomas Adam

2012/9/24 Thomas Adam <thomas@...>:
> On 23 September 2012 20:56, Sergey Naumov <sknaumov@...> wrote:
>> Also, could you explain how to detect if there is a up/down space
>> outside visible area we can scroll to? I have surfed  the code a bit a
>> have tried screen->grid->hsize, because screen_resize_y() uses it to
>> check if there is some lines to pull to new lines, but without success
>> - when we a scrolling, gd->hsize==0. If we can check in
>> window_copy_mouse() that there is a space to scroll to, we can send
>> scroll_only==1 to window_copy_cursor_up().
>
> If your aim is to get scrolling without affecting the position of the
> cursor when you enter copy-mode, there's been a patch for this sent to
> this list recently -- but it's still very much in review.
>
> -- Thomas Adam

Can't find this patch in mailing list history (for last 3 months), but
it seems that attached patch is all what have to be done to hardcode
"scroll first then move cursor" behavior. Unfortunately my tmux
knowledge is not good enough yet to quickly write fully configurable
patch.
At weekends I will try to research how to determine that we are in a
"real" terminal, not in a terminal program like mc or vim. Then it
will be possible to automatically enter copy mode at the "real"
terminal, but use mouse as usual in terminal programs.

Sincerely yours,
Sergey Naumov.

This version should work better - just like in mc and mcedit.
Haven't checked whether screen_size_y(s) - 1 is still valid if there
is no statusbar, but idea is clear.

Sergey Naumov.

2012/9/24 Sergey Naumov <sknaumov@...>:
> 2012/9/24 Thomas Adam <thomas@...>:
>> On 23 September 2012 20:56, Sergey Naumov <sknaumov@...> wrote:
>>> Also, could you explain how to detect if there is a up/down space
>>> outside visible area we can scroll to? I have surfed  the code a bit a
>>> have tried screen->grid->hsize, because screen_resize_y() uses it to
>>> check if there is some lines to pull to new lines, but without success
>>> - when we a scrolling, gd->hsize==0. If we can check in
>>> window_copy_mouse() that there is a space to scroll to, we can send
>>> scroll_only==1 to window_copy_cursor_up().
>>
>> If your aim is to get scrolling without affecting the position of the
>> cursor when you enter copy-mode, there's been a patch for this sent to
>> this list recently -- but it's still very much in review.
>>
>> -- Thomas Adam
>
> Can't find this patch in mailing list history (for last 3 months), but
> it seems that attached patch is all what have to be done to hardcode
> "scroll first then move cursor" behavior. Unfortunately my tmux
> knowledge is not good enough yet to quickly write fully configurable
> patch.
> At weekends I will try to research how to determine that we are in a
> "real" terminal, not in a terminal program like mc or vim. Then it
> will be possible to automatically enter copy mode at the "real"
> terminal, but use mouse as usual in terminal programs.
>
> Sincerely yours,
> Sergey Naumov.

On 24 September 2012 21:24, Sergey Naumov <sknaumov@...> wrote:
> This version should work better - just like in mc and mcedit.
> Haven't checked whether screen_size_y(s) - 1 is still valid if there
> is no statusbar, but idea is clear.

I synced git HEAD earlier -- that should contain a patch like this.

-- Thomas Adam

On 24 September 2012 20:57, Sergey Naumov <sknaumov@...> wrote:
> At weekends I will try to research how to determine that we are in a
> "real" terminal, not in a terminal program like mc or vim. Then it
> will be possible to automatically enter copy mode at the "real"
> terminal, but use mouse as usual in terminal programs.

Regardless of this feature (which is now in git HEAD) your logic is
flawed regarding the circumstances of this -- what if I want to scroll
through some program's output, for instance?

-- Thomas Adam

You can tell by checking whether the program has itself enabled the
mouse (wp->base.mode & ALL_MOUSE_MODES).


On Mon, Sep 24, 2012 at 10:56:17PM +0100, Thomas Adam wrote:
> On 24 September 2012 20:57, Sergey Naumov <sknaumov@...> wrote:
> > At weekends I will try to research how to determine that we are in a
> > "real" terminal, not in a terminal program like mc or vim. Then it
> > will be possible to automatically enter copy mode at the "real"
> > terminal, but use mouse as usual in terminal programs.
> 
> Regardless of this feature (which is now in git HEAD) your logic is
> flawed regarding the circumstances of this -- what if I want to scroll
> through some program's output, for instance?
> 
> -- Thomas Adam
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> tmux-users mailing list
> tmux-users@...
> https://lists.sourceforge.net/lists/listinfo/tmux-users

I have just pulled, compiled and installed the latest tmux and can't
see any changes. Could you tell me a commit hash?

There is also no new option to select desired behavior:

sknaumov@...$ git remote -v
origin  git://tmux.git.sourceforge.net/gitroot/tmux/tmux (fetch)
origin  git://tmux.git.sourceforge.net/gitroot/tmux/tmux (push)
sknaumov@...$ git pull --rebase
Current branch master is up to date.

sknaumov@...$ git log -1 -- options-table.c
commit b728970c654cc16476f4e923cb435512d20b47f3
Author: Tiago Cunha <tcunha@...>
Date:   Thu May 3 17:51:04 2012 +0000

    Sync OpenBSD patchset 1104:

    Add a flag to move-window to renumber the windows in a session (closing
    any gaps) and add an option to do this automatically each time a window
    is killed. From Thomas Adam.

2012/9/25 Thomas Adam <thomas@...>:
> On 24 September 2012 21:24, Sergey Naumov <sknaumov@...> wrote:
>> This version should work better - just like in mc and mcedit.
>> Haven't checked whether screen_size_y(s) - 1 is still valid if there
>> is no statusbar, but idea is clear.
>
> I synced git HEAD earlier -- that should contain a patch like this.
>
> -- Thomas Adam

2012/9/25 Nicholas Marriott <nicholas.marriott@...>:
> You can tell by checking whether the program has itself enabled the
> mouse (wp->base.mode & ALL_MOUSE_MODES).

Yes, this works like a charm (at least in mc and mcedit on xterm):

sknaumov@...$ git diff HEAD
diff --git a/input-keys.c b/input-keys.c
index 2b30d4b..3b049e0 100644
--- a/input-keys.c
+++ b/input-keys.c
@@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct mouse_event *m)
        }

        if ((m->b & 3) != 1 &&
-           options_get_number(&wp->window->options, "mode-mouse") == 1) {
+           options_get_number(&wp->window->options, "mode-mouse") == 1 &&
+           (wp->base.mode & ALL_MOUSE_MODES)) {
                if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
                        window_copy_init_from_pane(wp);
                        if (wp->mode->mouse != NULL)

>> Regardless of this feature (which is now in git HEAD) your logic is
>> flawed regarding the circumstances of this -- what if I want to scroll
>> through some program's output, for instance?
>>
>> -- Thomas Adam

I think that in most cases programs that enable mouse support
scrolling too, but it could be easily done as an option, for example
let's add one more mode: off, copy-mode, on, always-on.
Or, to preserve backward compatibility: off, copy-mode, terminal, on.

Sergey Naumov.

So you want to only enter copy mode when the program has already claimed
the mouse? Or am I reading this wrong?


On Sun, Sep 30, 2012 at 10:05:00PM +0400, Sergey Naumov wrote:
> 2012/9/25 Nicholas Marriott <nicholas.marriott@...>:
> > You can tell by checking whether the program has itself enabled the
> > mouse (wp->base.mode & ALL_MOUSE_MODES).
> 
> Yes, this works like a charm (at least in mc and mcedit on xterm):
> 
> sknaumov@...$ git diff HEAD
> diff --git a/input-keys.c b/input-keys.c
> index 2b30d4b..3b049e0 100644
> --- a/input-keys.c
> +++ b/input-keys.c
> @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct mouse_event *m)
>         }
> 
>         if ((m->b & 3) != 1 &&
> -           options_get_number(&wp->window->options, "mode-mouse") == 1) {
> +           options_get_number(&wp->window->options, "mode-mouse") == 1 &&
> +           (wp->base.mode & ALL_MOUSE_MODES)) {
>                 if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
>                         window_copy_init_from_pane(wp);
>                         if (wp->mode->mouse != NULL)
> 
> >> Regardless of this feature (which is now in git HEAD) your logic is
> >> flawed regarding the circumstances of this -- what if I want to scroll
> >> through some program's output, for instance?
> >>
> >> -- Thomas Adam
> 
> I think that in most cases programs that enable mouse support
> scrolling too, but it could be easily done as an option, for example
> let's add one more mode: off, copy-mode, on, always-on.
> Or, to preserve backward compatibility: off, copy-mode, terminal, on.
> 
> Sergey Naumov.

No, I want to enter copy mode when I am in terminal with shell prompt
(and it is better to have an option to scroll first then move cursor
when we reached a top of history, because it resembles original mouse
scrolling in terminal), but I want to use program-implemented mouse
scrolling in terminal program (and I always can enter copy mode with
Ctrl-a [, so this logic is not flawed, I think).
With this aptch applied I can use mouse scrolling within mc and mcedit
to select files/navigate through code, but when I press Ctrl-o (switch
to mc internal subshell), I can scroll mouse to enter copy mode and
look at terminal history.

Sergey Naumov.

2012/10/26, Nicholas Marriott <nicholas.marriott@...>:
> So you want to only enter copy mode when the program has already claimed
> the mouse? Or am I reading this wrong?
>
>
> On Sun, Sep 30, 2012 at 10:05:00PM +0400, Sergey Naumov wrote:
>> 2012/9/25 Nicholas Marriott <nicholas.marriott@...>:
>> > You can tell by checking whether the program has itself enabled the
>> > mouse (wp->base.mode & ALL_MOUSE_MODES).
>>
>> Yes, this works like a charm (at least in mc and mcedit on xterm):
>>
>> sknaumov@...$ git diff HEAD
>> diff --git a/input-keys.c b/input-keys.c
>> index 2b30d4b..3b049e0 100644
>> --- a/input-keys.c
>> +++ b/input-keys.c
>> @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct mouse_event
>> *m)
>>         }
>>
>>         if ((m->b & 3) != 1 &&
>> -           options_get_number(&wp->window->options, "mode-mouse") == 1)
>> {
>> +           options_get_number(&wp->window->options, "mode-mouse") == 1
>> &&
>> +           (wp->base.mode & ALL_MOUSE_MODES)) {
>>                 if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
>>                         window_copy_init_from_pane(wp);
>>                         if (wp->mode->mouse != NULL)
>>
>> >> Regardless of this feature (which is now in git HEAD) your logic is
>> >> flawed regarding the circumstances of this -- what if I want to scroll
>> >> through some program's output, for instance?
>> >>
>> >> -- Thomas Adam
>>
>> I think that in most cases programs that enable mouse support
>> scrolling too, but it could be easily done as an option, for example
>> let's add one more mode: off, copy-mode, on, always-on.
>> Or, to preserve backward compatibility: off, copy-mode, terminal, on.
>>
>> Sergey Naumov.
>

Yes, of course, there have to be a negation:
sknaumov@...$ git diff HEAD
diff --git a/input-keys.c b/input-keys.c
index 2b30d4b..b39d024 100644
--- a/input-keys.c
+++ b/input-keys.c
@@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct mouse_event *m)
        }

        if ((m->b & 3) != 1 &&
-           options_get_number(&wp->window->options, "mode-mouse") == 1) {
+           options_get_number(&wp->window->options, "mode-mouse") == 1 &&
+           !(wp->base.mode & ALL_MOUSE_MODES)) {
                if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
                        window_copy_init_from_pane(wp);
                        if (wp->mode->mouse != NULL)

2012/10/26 Sergey Naumov <sknaumov@...>:
> No, I want to enter copy mode when I am in terminal with shell prompt
> (and it is better to have an option to scroll first then move cursor
> when we reached a top of history, because it resembles original mouse
> scrolling in terminal), but I want to use program-implemented mouse
> scrolling in terminal program (and I always can enter copy mode with
> Ctrl-a [, so this logic is not flawed, I think).
> With this aptch applied I can use mouse scrolling within mc and mcedit
> to select files/navigate through code, but when I press Ctrl-o (switch
> to mc internal subshell), I can scroll mouse to enter copy mode and
> look at terminal history.
>
> Sergey Naumov.
>
> 2012/10/26, Nicholas Marriott <nicholas.marriott@...>:
>> So you want to only enter copy mode when the program has already claimed
>> the mouse? Or am I reading this wrong?
>>
>>
>> On Sun, Sep 30, 2012 at 10:05:00PM +0400, Sergey Naumov wrote:
>>> 2012/9/25 Nicholas Marriott <nicholas.marriott@...>:
>>> > You can tell by checking whether the program has itself enabled the
>>> > mouse (wp->base.mode & ALL_MOUSE_MODES).
>>>
>>> Yes, this works like a charm (at least in mc and mcedit on xterm):
>>>
>>> sknaumov@...$ git diff HEAD
>>> diff --git a/input-keys.c b/input-keys.c
>>> index 2b30d4b..3b049e0 100644
>>> --- a/input-keys.c
>>> +++ b/input-keys.c
>>> @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct mouse_event
>>> *m)
>>>         }
>>>
>>>         if ((m->b & 3) != 1 &&
>>> -           options_get_number(&wp->window->options, "mode-mouse") == 1)
>>> {
>>> +           options_get_number(&wp->window->options, "mode-mouse") == 1
>>> &&
>>> +           (wp->base.mode & ALL_MOUSE_MODES)) {
>>>                 if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
>>>                         window_copy_init_from_pane(wp);
>>>                         if (wp->mode->mouse != NULL)
>>>
>>> >> Regardless of this feature (which is now in git HEAD) your logic is
>>> >> flawed regarding the circumstances of this -- what if I want to scroll
>>> >> through some program's output, for instance?
>>> >>
>>> >> -- Thomas Adam
>>>
>>> I think that in most cases programs that enable mouse support
>>> scrolling too, but it could be easily done as an option, for example
>>> let's add one more mode: off, copy-mode, on, always-on.
>>> Or, to preserve backward compatibility: off, copy-mode, terminal, on.
>>>
>>> Sergey Naumov.
>>

Applied, thnaks.



On Fri, Oct 26, 2012 at 08:09:17PM +0400, Sergey Naumov wrote:
> Yes, of course, there have to be a negation:
> sknaumov@...$ git diff HEAD
> diff --git a/input-keys.c b/input-keys.c
> index 2b30d4b..b39d024 100644
> --- a/input-keys.c
> +++ b/input-keys.c
> @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct mouse_event *m)
>         }
> 
>         if ((m->b & 3) != 1 &&
> -           options_get_number(&wp->window->options, "mode-mouse") == 1) {
> +           options_get_number(&wp->window->options, "mode-mouse") == 1 &&
> +           !(wp->base.mode & ALL_MOUSE_MODES)) {
>                 if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
>                         window_copy_init_from_pane(wp);
>                         if (wp->mode->mouse != NULL)
> 
> 2012/10/26 Sergey Naumov <sknaumov@...>:
> > No, I want to enter copy mode when I am in terminal with shell prompt
> > (and it is better to have an option to scroll first then move cursor
> > when we reached a top of history, because it resembles original mouse
> > scrolling in terminal), but I want to use program-implemented mouse
> > scrolling in terminal program (and I always can enter copy mode with
> > Ctrl-a [, so this logic is not flawed, I think).
> > With this aptch applied I can use mouse scrolling within mc and mcedit
> > to select files/navigate through code, but when I press Ctrl-o (switch
> > to mc internal subshell), I can scroll mouse to enter copy mode and
> > look at terminal history.
> >
> > Sergey Naumov.
> >
> > 2012/10/26, Nicholas Marriott <nicholas.marriott@...>:
> >> So you want to only enter copy mode when the program has already claimed
> >> the mouse? Or am I reading this wrong?
> >>
> >>
> >> On Sun, Sep 30, 2012 at 10:05:00PM +0400, Sergey Naumov wrote:
> >>> 2012/9/25 Nicholas Marriott <nicholas.marriott@...>:
> >>> > You can tell by checking whether the program has itself enabled the
> >>> > mouse (wp->base.mode & ALL_MOUSE_MODES).
> >>>
> >>> Yes, this works like a charm (at least in mc and mcedit on xterm):
> >>>
> >>> sknaumov@...$ git diff HEAD
> >>> diff --git a/input-keys.c b/input-keys.c
> >>> index 2b30d4b..3b049e0 100644
> >>> --- a/input-keys.c
> >>> +++ b/input-keys.c
> >>> @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct mouse_event
> >>> *m)
> >>>         }
> >>>
> >>>         if ((m->b & 3) != 1 &&
> >>> -           options_get_number(&wp->window->options, "mode-mouse") == 1)
> >>> {
> >>> +           options_get_number(&wp->window->options, "mode-mouse") == 1
> >>> &&
> >>> +           (wp->base.mode & ALL_MOUSE_MODES)) {
> >>>                 if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
> >>>                         window_copy_init_from_pane(wp);
> >>>                         if (wp->mode->mouse != NULL)
> >>>
> >>> >> Regardless of this feature (which is now in git HEAD) your logic is
> >>> >> flawed regarding the circumstances of this -- what if I want to scroll
> >>> >> through some program's output, for instance?
> >>> >>
> >>> >> -- Thomas Adam
> >>>
> >>> I think that in most cases programs that enable mouse support
> >>> scrolling too, but it could be easily done as an option, for example
> >>> let's add one more mode: off, copy-mode, on, always-on.
> >>> Or, to preserve backward compatibility: off, copy-mode, terminal, on.
> >>>
> >>> Sergey Naumov.
> >>

Actually, I've reverted this. When I use "mode-mouse on" with
applications inside that claim the mouse (easiest example is another
tmux server with mouse-select-pane and the window split) it works fine.

Do I misunderstand what you are trying to fix?


On Tue, Nov 27, 2012 at 02:23:03PM +0000, Nicholas Marriott wrote:
> Applied, thnaks.
> 
> 
> 
> On Fri, Oct 26, 2012 at 08:09:17PM +0400, Sergey Naumov wrote:
> > Yes, of course, there have to be a negation:
> > sknaumov@...$ git diff HEAD
> > diff --git a/input-keys.c b/input-keys.c
> > index 2b30d4b..b39d024 100644
> > --- a/input-keys.c
> > +++ b/input-keys.c
> > @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct mouse_event *m)
> >         }
> > 
> >         if ((m->b & 3) != 1 &&
> > -           options_get_number(&wp->window->options, "mode-mouse") == 1) {
> > +           options_get_number(&wp->window->options, "mode-mouse") == 1 &&
> > +           !(wp->base.mode & ALL_MOUSE_MODES)) {
> >                 if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
> >                         window_copy_init_from_pane(wp);
> >                         if (wp->mode->mouse != NULL)
> > 
> > 2012/10/26 Sergey Naumov <sknaumov@...>:
> > > No, I want to enter copy mode when I am in terminal with shell prompt
> > > (and it is better to have an option to scroll first then move cursor
> > > when we reached a top of history, because it resembles original mouse
> > > scrolling in terminal), but I want to use program-implemented mouse
> > > scrolling in terminal program (and I always can enter copy mode with
> > > Ctrl-a [, so this logic is not flawed, I think).
> > > With this aptch applied I can use mouse scrolling within mc and mcedit
> > > to select files/navigate through code, but when I press Ctrl-o (switch
> > > to mc internal subshell), I can scroll mouse to enter copy mode and
> > > look at terminal history.
> > >
> > > Sergey Naumov.
> > >
> > > 2012/10/26, Nicholas Marriott <nicholas.marriott@...>:
> > >> So you want to only enter copy mode when the program has already claimed
> > >> the mouse? Or am I reading this wrong?
> > >>
> > >>
> > >> On Sun, Sep 30, 2012 at 10:05:00PM +0400, Sergey Naumov wrote:
> > >>> 2012/9/25 Nicholas Marriott <nicholas.marriott@...>:
> > >>> > You can tell by checking whether the program has itself enabled the
> > >>> > mouse (wp->base.mode & ALL_MOUSE_MODES).
> > >>>
> > >>> Yes, this works like a charm (at least in mc and mcedit on xterm):
> > >>>
> > >>> sknaumov@...$ git diff HEAD
> > >>> diff --git a/input-keys.c b/input-keys.c
> > >>> index 2b30d4b..3b049e0 100644
> > >>> --- a/input-keys.c
> > >>> +++ b/input-keys.c
> > >>> @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct mouse_event
> > >>> *m)
> > >>>         }
> > >>>
> > >>>         if ((m->b & 3) != 1 &&
> > >>> -           options_get_number(&wp->window->options, "mode-mouse") == 1)
> > >>> {
> > >>> +           options_get_number(&wp->window->options, "mode-mouse") == 1
> > >>> &&
> > >>> +           (wp->base.mode & ALL_MOUSE_MODES)) {
> > >>>                 if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
> > >>>                         window_copy_init_from_pane(wp);
> > >>>                         if (wp->mode->mouse != NULL)
> > >>>
> > >>> >> Regardless of this feature (which is now in git HEAD) your logic is
> > >>> >> flawed regarding the circumstances of this -- what if I want to scroll
> > >>> >> through some program's output, for instance?
> > >>> >>
> > >>> >> -- Thomas Adam
> > >>>
> > >>> I think that in most cases programs that enable mouse support
> > >>> scrolling too, but it could be easily done as an option, for example
> > >>> let's add one more mode: off, copy-mode, on, always-on.
> > >>> Or, to preserve backward compatibility: off, copy-mode, terminal, on.
> > >>>
> > >>> Sergey Naumov.
> > >>

I can't check it right now at work because build on Debian Squeeze is broken:

control.c: In function ‘control_callback’:
control.c:103: warning: implicit declaration of function ‘evbuffer_readln’
control.c:103: warning: nested extern declaration of ‘evbuffer_readln’
control.c:103: error: ‘EVBUFFER_EOL_LF’ undeclared (first use in this function)
control.c:103: error: (Each undeclared identifier is reported only once
control.c:103: error: for each function it appears in.)

As far as I understand, EVBUFFER_EOL_LF is from libevent, but I have
libevent-dev package installed.

At home I will pull last changes from tmux git and give you a feedback.

Sergey Naumov.



2012/11/27, Nicholas Marriott <nicholas.marriott@...>:
> Actually, I've reverted this. When I use "mode-mouse on" with
> applications inside that claim the mouse (easiest example is another
> tmux server with mouse-select-pane and the window split) it works fine.
>
> Do I misunderstand what you are trying to fix?
>
>
> On Tue, Nov 27, 2012 at 02:23:03PM +0000, Nicholas Marriott wrote:
>> Applied, thnaks.
>>
>>
>>
>> On Fri, Oct 26, 2012 at 08:09:17PM +0400, Sergey Naumov wrote:
>> > Yes, of course, there have to be a negation:
>> > sknaumov@...$ git diff HEAD
>> > diff --git a/input-keys.c b/input-keys.c
>> > index 2b30d4b..b39d024 100644
>> > --- a/input-keys.c
>> > +++ b/input-keys.c
>> > @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct
>> > mouse_event *m)
>> >         }
>> >
>> >         if ((m->b & 3) != 1 &&
>> > -           options_get_number(&wp->window->options, "mode-mouse") == 1)
>> > {
>> > +           options_get_number(&wp->window->options, "mode-mouse") == 1
>> > &&
>> > +           !(wp->base.mode & ALL_MOUSE_MODES)) {
>> >                 if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
>> >                         window_copy_init_from_pane(wp);
>> >                         if (wp->mode->mouse != NULL)
>> >
>> > 2012/10/26 Sergey Naumov <sknaumov@...>:
>> > > No, I want to enter copy mode when I am in terminal with shell prompt
>> > > (and it is better to have an option to scroll first then move cursor
>> > > when we reached a top of history, because it resembles original mouse
>> > > scrolling in terminal), but I want to use program-implemented mouse
>> > > scrolling in terminal program (and I always can enter copy mode with
>> > > Ctrl-a [, so this logic is not flawed, I think).
>> > > With this aptch applied I can use mouse scrolling within mc and
>> > > mcedit
>> > > to select files/navigate through code, but when I press Ctrl-o
>> > > (switch
>> > > to mc internal subshell), I can scroll mouse to enter copy mode and
>> > > look at terminal history.
>> > >
>> > > Sergey Naumov.
>> > >
>> > > 2012/10/26, Nicholas Marriott <nicholas.marriott@...>:
>> > >> So you want to only enter copy mode when the program has already
>> > >> claimed
>> > >> the mouse? Or am I reading this wrong?
>> > >>
>> > >>
>> > >> On Sun, Sep 30, 2012 at 10:05:00PM +0400, Sergey Naumov wrote:
>> > >>> 2012/9/25 Nicholas Marriott <nicholas.marriott@...>:
>> > >>> > You can tell by checking whether the program has itself enabled
>> > >>> > the
>> > >>> > mouse (wp->base.mode & ALL_MOUSE_MODES).
>> > >>>
>> > >>> Yes, this works like a charm (at least in mc and mcedit on xterm):
>> > >>>
>> > >>> sknaumov@...$ git diff HEAD
>> > >>> diff --git a/input-keys.c b/input-keys.c
>> > >>> index 2b30d4b..3b049e0 100644
>> > >>> --- a/input-keys.c
>> > >>> +++ b/input-keys.c
>> > >>> @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct
>> > >>> mouse_event
>> > >>> *m)
>> > >>>         }
>> > >>>
>> > >>>         if ((m->b & 3) != 1 &&
>> > >>> -           options_get_number(&wp->window->options, "mode-mouse")
>> > >>> == 1)
>> > >>> {
>> > >>> +           options_get_number(&wp->window->options, "mode-mouse")
>> > >>> == 1
>> > >>> &&
>> > >>> +           (wp->base.mode & ALL_MOUSE_MODES)) {
>> > >>>                 if (window_pane_set_mode(wp, &window_copy_mode) ==
>> > >>> 0) {
>> > >>>                         window_copy_init_from_pane(wp);
>> > >>>                         if (wp->mode->mouse != NULL)
>> > >>>
>> > >>> >> Regardless of this feature (which is now in git HEAD) your logic
>> > >>> >> is
>> > >>> >> flawed regarding the circumstances of this -- what if I want to
>> > >>> >> scroll
>> > >>> >> through some program's output, for instance?
>> > >>> >>
>> > >>> >> -- Thomas Adam
>> > >>>
>> > >>> I think that in most cases programs that enable mouse support
>> > >>> scrolling too, but it could be easily done as an option, for
>> > >>> example
>> > >>> let's add one more mode: off, copy-mode, on, always-on.
>> > >>> Or, to preserve backward compatibility: off, copy-mode, terminal,
>> > >>> on.
>> > >>>
>> > >>> Sergey Naumov.
>> > >>
>

Hi,

On 28 November 2012 07:02, Sergey Naumov <sknaumov@...> wrote:
> I can't check it right now at work because build on Debian Squeeze is broken:
>
> control.c: In function ‘control_callback’:
> control.c:103: warning: implicit declaration of function ‘evbuffer_readln’
> control.c:103: warning: nested extern declaration of ‘evbuffer_readln’
> control.c:103: error: ‘EVBUFFER_EOL_LF’ undeclared (first use in this function)
> control.c:103: error: (Each undeclared identifier is reported only once
> control.c:103: error: for each function it appears in.)
>
> As far as I understand, EVBUFFER_EOL_LF is from libevent, but I have
> libevent-dev package installed.

That's still an old version.  Use either libevent-1.4.14b or libevent-2.0.21

This question comes up *a lot*.

-- Thomas Adam

I have pulled the last changes from tmux repo and tested it on xubuntu
12.10. Copy-mode entrance and exit works as it should in case of
copy-mode=on. Two mounths ago (last commit was dated 27 september) it
doesn't (mc even with -x option didn't react on mouse wheel without my
patch).
By the way, scrolling tmux history with mouse become very convenient too:
it scrolls history from the very beginning instead of moving cursor up.

Great job and thank you, guys!


2012/11/27 Nicholas Marriott <nicholas.marriott@...>

> Actually, I've reverted this. When I use "mode-mouse on" with
> applications inside that claim the mouse (easiest example is another
> tmux server with mouse-select-pane and the window split) it works fine.
>
> Do I misunderstand what you are trying to fix?
>
>
> On Tue, Nov 27, 2012 at 02:23:03PM +0000, Nicholas Marriott wrote:
> > Applied, thnaks.
> >
> >
> >
> > On Fri, Oct 26, 2012 at 08:09:17PM +0400, Sergey Naumov wrote:
> > > Yes, of course, there have to be a negation:
> > > sknaumov@...$ git diff HEAD
> > > diff --git a/input-keys.c b/input-keys.c
> > > index 2b30d4b..b39d024 100644
> > > --- a/input-keys.c
> > > +++ b/input-keys.c
> > > @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct
> mouse_event *m)
> > >         }
> > >
> > >         if ((m->b & 3) != 1 &&
> > > -           options_get_number(&wp->window->options, "mode-mouse") ==
> 1) {
> > > +           options_get_number(&wp->window->options, "mode-mouse") ==
> 1 &&
> > > +           !(wp->base.mode & ALL_MOUSE_MODES)) {
> > >                 if (window_pane_set_mode(wp, &window_copy_mode) == 0) {
> > >                         window_copy_init_from_pane(wp);
> > >                         if (wp->mode->mouse != NULL)
> > >
> > > 2012/10/26 Sergey Naumov <sknaumov@...>:
> > > > No, I want to enter copy mode when I am in terminal with shell prompt
> > > > (and it is better to have an option to scroll first then move cursor
> > > > when we reached a top of history, because it resembles original mouse
> > > > scrolling in terminal), but I want to use program-implemented mouse
> > > > scrolling in terminal program (and I always can enter copy mode with
> > > > Ctrl-a [, so this logic is not flawed, I think).
> > > > With this aptch applied I can use mouse scrolling within mc and
> mcedit
> > > > to select files/navigate through code, but when I press Ctrl-o
> (switch
> > > > to mc internal subshell), I can scroll mouse to enter copy mode and
> > > > look at terminal history.
> > > >
> > > > Sergey Naumov.
> > > >
> > > > 2012/10/26, Nicholas Marriott <nicholas.marriott@...>:
> > > >> So you want to only enter copy mode when the program has already
> claimed
> > > >> the mouse? Or am I reading this wrong?
> > > >>
> > > >>
> > > >> On Sun, Sep 30, 2012 at 10:05:00PM +0400, Sergey Naumov wrote:
> > > >>> 2012/9/25 Nicholas Marriott <nicholas.marriott@...>:
> > > >>> > You can tell by checking whether the program has itself enabled
> the
> > > >>> > mouse (wp->base.mode & ALL_MOUSE_MODES).
> > > >>>
> > > >>> Yes, this works like a charm (at least in mc and mcedit on xterm):
> > > >>>
> > > >>> sknaumov@...$ git diff HEAD
> > > >>> diff --git a/input-keys.c b/input-keys.c
> > > >>> index 2b30d4b..3b049e0 100644
> > > >>> --- a/input-keys.c
> > > >>> +++ b/input-keys.c
> > > >>> @@ -223,7 +223,8 @@ input_mouse(struct window_pane *wp, struct
> mouse_event
> > > >>> *m)
> > > >>>         }
> > > >>>
> > > >>>         if ((m->b & 3) != 1 &&
> > > >>> -           options_get_number(&wp->window->options, "mode-mouse")
> == 1)
> > > >>> {
> > > >>> +           options_get_number(&wp->window->options, "mode-mouse")
> == 1
> > > >>> &&
> > > >>> +           (wp->base.mode & ALL_MOUSE_MODES)) {
> > > >>>                 if (window_pane_set_mode(wp, &window_copy_mode) ==
> 0) {
> > > >>>                         window_copy_init_from_pane(wp);
> > > >>>                         if (wp->mode->mouse != NULL)
> > > >>>
> > > >>> >> Regardless of this feature (which is now in git HEAD) your
> logic is
> > > >>> >> flawed regarding the circumstances of this -- what if I want to
> scroll
> > > >>> >> through some program's output, for instance?
> > > >>> >>
> > > >>> >> -- Thomas Adam
> > > >>>
> > > >>> I think that in most cases programs that enable mouse support
> > > >>> scrolling too, but it could be easily done as an option, for
> example
> > > >>> let's add one more mode: off, copy-mode, on, always-on.
> > > >>> Or, to preserve backward compatibility: off, copy-mode, terminal,
> on.
> > > >>>
> > > >>> Sergey Naumov.
> > > >>
>