[dev] [st] no focus events inside tmux

[Amer]

Prerequisites:
Tiling WM i3wm / xmonad -- not related to bug.
And tmux has in tmux.conf
set -g focus-events on

Test case for bug:
Open empty terminal
st -e tmux
Activate focusing
printf "\e[?1004h"
Catch one focus event
<C-v>
Move focus to another window
Expected: printed ^[[O in place of pending ^
Actual result: nothing changed

Same test case works as expected in xterm, but not in st.
Therefore I treat this misbehavior as bug.
But I haven't found any related problems inside sources.

Of course, all OK for bare st without tmux.
And we receive focus events in st+tmux when changing active pane.
But never, when we change focus of actual window.

[k***@shike2.com]

Hi,

Post by Amer
Move focus to another window
Expected: printed ^[[O in place of pending ^
Actual result: nothing changed

I have tested it in dwm and git st and I receive a ^[[O.
Can you try it with dwm and send the results?

Regards,

[k***@shike2.com]

Hi again,

Post by Amer
Open empty terminal
st -e tmux
Activate focusing
printf "\e[?1004h"
Catch one focus event
<C-v>
Move focus to another window
Expected: printed ^[[O in place of pending ^
Actual result: nothing changed

I mistook in my previos mail. My session in tmux is:


$ printf "\e[?1004h"
^[[I$

and in st:

$ st -e tmux
erresc: unknown private set/reset mode 1005

As you can see tmux is printing \e[?1005 to st, and
the question is, why?. We don't have this sequence
in any of the capabilities of our terminfo entry,
so I suspect that tmux has it hardcoded. Look in
the code of tmux to see why \e[?1005h is printed.
In fact, we have 1000,1002,1003,1004 and 1006.
I don't know what 1005 does, so this information
may be interesting to.

Regards,

[Amer]

On Wed, Mar 30, 2016 at 08:17:39AM +0200, ***@shike2.com wrote:

Hi,
I'm glad someone finally tried it.:)

Post by k***@shike2.com
$ printf "\e[?1004h"
^[[I$

Because it don't work for me in dwm either.

Let's make more detailed test case:
$ sudo pacman -S st dwm # Actually: st-0.6.3, dwm-6.1-3
$ cat ~/.tmux.conf
set -g default-command /bin/bash
set -g focus-events on

In dwm:
- A-S-<Enter> # to launch first _bare_ terminal
$ st # to launch terminal from another
$ tmux -L test # independent tmux server
$ printf "\e[?1004h"
- <C-v>
- A-j/k

Results:
- cursor slightly blinks, which indicates focus lost/gain
- but nothing printed (no focus in/out events in tmux)
- however on splitting tmux C-b % those events immediately shown

WBR,

Post by k***@shike2.com
$ st -e tmux
erresc: unknown private set/reset mode 1005
As you can see tmux is printing \e[?1005 to st, and
the question is, why?. We don't have this sequence
in any of the capabilities of our terminfo entry,
so I suspect that tmux has it hardcoded. Look in
the code of tmux to see why \e[?1005h is printed.
In fact, we have 1000,1002,1003,1004 and 1006.
I don't know what 1005 does, so this information
may be interesting to.

I will look at it by curiosity, however if you really could make it
work on your accord, then it's not strictly related to problem.

[k***@shike2.com]

Hi,

Post by Amer
I'm glad someone finally tried it.:)

I'm sorry. I am setting my network now, and I cannot read
the mail as fast as I used to do it. BTW, the another
maintainer shold have to answer, but he is a bit lazy ...
I mistook, I didn't receive it.

Post by Amer
$ sudo pacman -S st dwm # Actually: st-0.6.3, dwm-6.1-3
$ cat ~/.tmux.conf
set -g default-command /bin/bash
set -g focus-events on
- A-S-<Enter> # to launch first _bare_ terminal
$ st # to launch terminal from another
$ tmux -L test # independent tmux server

At this point you get a \e[?1005h in the terminal because tmux
is trying to see what is the correct mode [1].

Post by Amer
$ printf "\e[?1004h"
- <C-v>
- A-j/k
- cursor slightly blinks, which indicates focus lost/gain
- but nothing printed (no focus in/out events in tmux)
- however on splitting tmux C-b % those events immediately shown

The code in st that handles it is very simpe:

case 1004: /* 1004: send focus events to tty */
MODBIT(term.mode, set, MODE_FOCUS);
break;
-----

void
focus(XEvent *ev)
{
XFocusChangeEvent *e = &ev->xfocus;

if (e->mode == NotifyGrab)
return;

if (ev->type == FocusIn) {
XSetICFocus(xw.xic);
xw.state |= WIN_FOCUSED;
xseturgency(0);
if (IS_SET(MODE_FOCUS))
ttywrite("\033[I", 3);
} else {
XUnsetICFocus(xw.xic);
xw.state &= ~WIN_FOCUSED;
if (IS_SET(MODE_FOCUS))
ttywrite("\033[O", 3);
}
}

We can try to test if we are receiving the event or not.
The posibilities here are:

- Mode is NotifyGrab
- We do not receive the event

I am a bit busy at this moment, but I will look it as soon as
possible.

Regards,

[1] https://github.com/tmux/tmux/blob/master/input-keys.c#L252

[k***@shike2.com]

Hi again,

Post by k***@shike2.com
We can try to test if we are receiving the event or not.
- Mode is NotifyGrab
- We do not receive the event

And the answer was: Any of them. We are not receiving the 1004
set mode sequence. I don't know why, but tmux think that is
better don't relay it to us.

I am going to look a bit deeper in the tmux link I posted here
the another day, but I am not very sure about the result.


Regards,

[Amer]

On Tue, Apr 05, 2016 at 12:08:15AM +0200, ***@shike2.com wrote:

Thanks for investigation,

It's likely that tmux checks some specific terminfo properties
before relaying 1004. If that's the case, we could temporarily
override them inside .tmux.conf to confirm and then add to compiled
st terminfo permanently.

Because, what else may be the reason, if st code seems OK to me,
but focus works as expected in xterm?

Post by k***@shike2.com
Hi again,

Post by k***@shike2.com
We can try to test if we are receiving the event or not.
- Mode is NotifyGrab
- We do not receive the event

And the answer was: Any of them. We are not receiving the 1004
set mode sequence. I don't know why, but tmux think that is
better don't relay it to us.
I am going to look a bit deeper in the tmux link I posted here
the another day, but I am not very sure about the result.
Regards,

[k***@shike2.com]

Post by Amer
It's likely that tmux checks some specific terminfo properties
before relaying 1004. If that's the case, we could temporarily
override them inside .tmux.conf to confirm and then add to compiled
st terminfo permanently.

Uhmmm, I dunno. As far as I know there is no terminfo
capability related motion events. Everything done related
to this topic is unportable by definition. I think the point
is that tmux doesn't support 1004, but it supports 1005 and
1006, which st doesn't support.

As you can read in the code of tmux:

/*
* Use the SGR (1006) extension only if the application requested it
* and the underlying terminal also sent the event in this format (this
* is because an old style mouse release event cannot be converted into
* the new SGR format, since the released button is unknown). Otherwise
* pretend that tmux doesn't speak this extension, and fall back to the
* UTF-8 (1005) extension if the application requested, or to the
* legacy format.
*/

I am only guesing. I will do some test tomorrow to see if it is
correct or not.

Post by Amer
Because, what else may be the reason, if st code seems OK to me,
but focus works as expected in xterm?

Because xterm supports 1004, 1005 and 1006.

Regards,