[mosh-devel] How to support xterm modifier key setting (CSI > Ps; Ps m)

[Erik Hons]

I'm trying to make emacs work well inside mintty/mosh. I'd like mintty
to send an alternate escape sequence for "C-Backspace" than the
default (which is "C-_"). There is an xterm sequence for this --
"\e[>4;1m" -- which sets the "modifyOtherKeys" resource. Emacs sends
that sequence on startup. When using ssh for remoting, the sequence is
passed to the client side, mintty sees it, and implements the desired
behavior.

The mosh terminal emulator appears to discard the sequence. There is
no matching function in terminal/terminalfunctions.cc defined for it,
so the dispatch process hits the "unknown function" condition in
terminal/***@226 (Dispatcher::dispatch()).

As an experiment, I've added a terminal function for "\e[>4;1m" and
confirmed that it sees the sequence when emacs sends it. I'm stuck on
what to do next.

It looks like I need to add something to Terminal::DrawState, then in
Display::new_frame() look for that member and call
frame.append("\e[>4;1m"); That's how the "mouse_reporting_mode" and
similar settings are handled.

But this might bring up a bigger question: How should the mosh
terminal emulator interact with the client side terminal emulator? I
can add support for this specific sequence, but maybe something more
general is warranted.

Any advice?

[Keith Winstein]

Hi Erik,

I'm a little confused why you want this in general, and it may relate to a
design weakness in Mosh, which is that it basically assumes that the client
terminal acts like an xterm. By default, an xterm sends Ctrl-H (0x08) when
the user types "Ctrl-Backspace" (and VTE seems to also follow this
convention). Mosh advertises to the remote host that it is an xterm (or
xterm-256color) and *basically* just sends bytes from the user's terminal
through to the host unchanged. For terminals that act a little differently
(e.g. rxvt), we have some long-lived bugs related to Mosh's failure to
translate from the terminal-generated escape codes to what the application
is (rightly) expecting from the advertised TERM type of
xterm/xterm-256color.

https://github.com/mobile-shell/mosh/issues/178

Maybe mintty and Ctrl-Backspace are in the same boat? If you want to help
us fix this bug overall, that would be awesome.

For the specific question, you basically have two options:

(a) Propagate this state change all the way through to the client terminal
emulator (which is what we do for mouse reporting), and continue to send
bytes unchanged in the client-to-server direction.

(b) Keep track of the state in the mosh-server only, and have the server
modify incoming bytes from the client before applying them to the terminal.
This is what we do for the "application mode" setting for the cursor keys.
See src/terminal/terminaluserinput.cc .

For this one, it seems like (b) might be sufficient... but really we should
just fix bug #178 overall in some clean way if that's the root cause.

-Keith

Post by Erik Hons
I'm trying to make emacs work well inside mintty/mosh. I'd like mintty
to send an alternate escape sequence for "C-Backspace" than the
default (which is "C-_"). There is an xterm sequence for this --
"\e[>4;1m" -- which sets the "modifyOtherKeys" resource. Emacs sends
that sequence on startup. When using ssh for remoting, the sequence is
passed to the client side, mintty sees it, and implements the desired
behavior.
The mosh terminal emulator appears to discard the sequence. There is
no matching function in terminal/terminalfunctions.cc defined for it,
so the dispatch process hits the "unknown function" condition in
As an experiment, I've added a terminal function for "\e[>4;1m" and
confirmed that it sees the sequence when emacs sends it. I'm stuck on
what to do next.
It looks like I need to add something to Terminal::DrawState, then in
Display::new_frame() look for that member and call
frame.append("\e[>4;1m"); That's how the "mouse_reporting_mode" and
similar settings are handled.
But this might bring up a bigger question: How should the mosh
terminal emulator interact with the client side terminal emulator? I
can add support for this specific sequence, but maybe something more
general is warranted.
Any advice?
_______________________________________________
mosh-devel mailing list
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[Erik Hons]

Hey Keith,

Thanks for writing back! I think my situation is different than the bug you
linked to. Let me see if I have this right:

Mosh always emulates and advertises itself to the application as an xterm,
regardless of what the user's terminal is. If the user's terminal doesn't
emulate an xterm exactly then there can be problems.

In bug #178 the user's terminal is sending non-xterm sequences for
Home/End. When mosh forwards those sequences, the application gets
confused. Fixing this would require mosh to understand all the non-xterm
terminals and "translate" to xterm sequences. No wonder that's an open
issue!

In my situation, I have a standard xterm sequence that is being sent by the
application to alter the user's xterm. This is almost the opposite
situation: mosh needs to forward that sequence from the application side to
the client side.

The effect is the client's terminal sends a different sequence for
C-backspace which makes it seem related to #178. But in this case, the
weird sequence is desired; having a unique sequence for C-backspace allows
emacs to do something different for that keycode.

Does that all make sense?

If so, then I think I need mosh to replicate the application's sequence on
the client side, just like it does for the mouse reporting mode. I would
add a resource-values member to Terminal::DrawState for the xterm settings,
and then watch for changes in Display::new_frame() sending the correct
sequence to the user's terminal there. I'm not sure how the serialization
works: Would I have to make any other changes?

Post by Keith Winstein
Hi Erik,
I'm a little confused why you want this in general, and it may relate to a
design weakness in Mosh, which is that it basically assumes that the client
terminal acts like an xterm. By default, an xterm sends Ctrl-H (0x08) when
the user types "Ctrl-Backspace" (and VTE seems to also follow this
convention). Mosh advertises to the remote host that it is an xterm (or
xterm-256color) and *basically* just sends bytes from the user's terminal
through to the host unchanged. For terminals that act a little differently
(e.g. rxvt), we have some long-lived bugs related to Mosh's failure to
translate from the terminal-generated escape codes to what the application
is (rightly) expecting from the advertised TERM type of
xterm/xterm-256color.
https://github.com/mobile-shell/mosh/issues/178
Maybe mintty and Ctrl-Backspace are in the same boat? If you want to help
us fix this bug overall, that would be awesome.
(a) Propagate this state change all the way through to the client terminal
emulator (which is what we do for mouse reporting), and continue to send
bytes unchanged in the client-to-server direction.
(b) Keep track of the state in the mosh-server only, and have the server
modify incoming bytes from the client before applying them to the terminal.
This is what we do for the "application mode" setting for the cursor keys.
See src/terminal/terminaluserinput.cc .
For this one, it seems like (b) might be sufficient... but really we
should just fix bug #178 overall in some clean way if that's the root cause.
-Keith

Post by Erik Hons
I'm trying to make emacs work well inside mintty/mosh. I'd like mintty
to send an alternate escape sequence for "C-Backspace" than the
default (which is "C-_"). There is an xterm sequence for this --
"\e[>4;1m" -- which sets the "modifyOtherKeys" resource. Emacs sends
that sequence on startup. When using ssh for remoting, the sequence is
passed to the client side, mintty sees it, and implements the desired
behavior.
The mosh terminal emulator appears to discard the sequence. There is
no matching function in terminal/terminalfunctions.cc defined for it,
so the dispatch process hits the "unknown function" condition in
As an experiment, I've added a terminal function for "\e[>4;1m" and
confirmed that it sees the sequence when emacs sends it. I'm stuck on
what to do next.
It looks like I need to add something to Terminal::DrawState, then in
Display::new_frame() look for that member and call
frame.append("\e[>4;1m"); That's how the "mouse_reporting_mode" and
similar settings are handled.
But this might bring up a bigger question: How should the mosh
terminal emulator interact with the client side terminal emulator? I
can add support for this specific sequence, but maybe something more
general is warranted.
Any advice?
_______________________________________________
mosh-devel mailing list
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[Erik Hons]

Hey, I tried it out and it worked! The patch needs more work, but is it on
the right track?

Post by Erik Hons
Hey Keith,
Thanks for writing back! I think my situation is different than the bug
Mosh always emulates and advertises itself to the application as an xterm,
regardless of what the user's terminal is. If the user's terminal doesn't
emulate an xterm exactly then there can be problems.
In bug #178 the user's terminal is sending non-xterm sequences for
Home/End. When mosh forwards those sequences, the application gets
confused. Fixing this would require mosh to understand all the non-xterm
terminals and "translate" to xterm sequences. No wonder that's an open
issue!
In my situation, I have a standard xterm sequence that is being sent by
the application to alter the user's xterm. This is almost the opposite
situation: mosh needs to forward that sequence from the application side to
the client side.
The effect is the client's terminal sends a different sequence for
C-backspace which makes it seem related to #178. But in this case, the
weird sequence is desired; having a unique sequence for C-backspace allows
emacs to do something different for that keycode.
Does that all make sense?
If so, then I think I need mosh to replicate the application's sequence on
the client side, just like it does for the mouse reporting mode. I would
add a resource-values member to Terminal::DrawState for the xterm settings,
and then watch for changes in Display::new_frame() sending the correct
sequence to the user's terminal there. I'm not sure how the serialization
works: Would I have to make any other changes?

Post by Keith Winstein
Hi Erik,
I'm a little confused why you want this in general, and it may relate to
a design weakness in Mosh, which is that it basically assumes that the
client terminal acts like an xterm. By default, an xterm sends Ctrl-H
(0x08) when the user types "Ctrl-Backspace" (and VTE seems to also follow
this convention). Mosh advertises to the remote host that it is an xterm
(or xterm-256color) and *basically* just sends bytes from the user's
terminal through to the host unchanged. For terminals that act a little
differently (e.g. rxvt), we have some long-lived bugs related to Mosh's
failure to translate from the terminal-generated escape codes to what the
application is (rightly) expecting from the advertised TERM type of
xterm/xterm-256color.
https://github.com/mobile-shell/mosh/issues/178
Maybe mintty and Ctrl-Backspace are in the same boat? If you want to help
us fix this bug overall, that would be awesome.
(a) Propagate this state change all the way through to the client
terminal emulator (which is what we do for mouse reporting), and continue
to send bytes unchanged in the client-to-server direction.
(b) Keep track of the state in the mosh-server only, and have the server
modify incoming bytes from the client before applying them to the terminal.
This is what we do for the "application mode" setting for the cursor keys.
See src/terminal/terminaluserinput.cc .
For this one, it seems like (b) might be sufficient... but really we
should just fix bug #178 overall in some clean way if that's the root cause.
-Keith

Post by Erik Hons
I'm trying to make emacs work well inside mintty/mosh. I'd like mintty
to send an alternate escape sequence for "C-Backspace" than the
default (which is "C-_"). There is an xterm sequence for this --
"\e[>4;1m" -- which sets the "modifyOtherKeys" resource. Emacs sends
that sequence on startup. When using ssh for remoting, the sequence is
passed to the client side, mintty sees it, and implements the desired
behavior.
The mosh terminal emulator appears to discard the sequence. There is
no matching function in terminal/terminalfunctions.cc defined for it,
so the dispatch process hits the "unknown function" condition in
As an experiment, I've added a terminal function for "\e[>4;1m" and
confirmed that it sees the sequence when emacs sends it. I'm stuck on
what to do next.
It looks like I need to add something to Terminal::DrawState, then in
Display::new_frame() look for that member and call
frame.append("\e[>4;1m"); That's how the "mouse_reporting_mode" and
similar settings are handled.
But this might bring up a bigger question: How should the mosh
terminal emulator interact with the client side terminal emulator? I
can add support for this specific sequence, but maybe something more
general is warranted.
Any advice?
_______________________________________________
mosh-devel mailing list
http://mailman.mit.edu/mailman/listinfo/mosh-devel