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

[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

On Sat, May 26, 2018 at 1:18 PM, Erik Hons <erik.hons at gmail.com> wrote:

> 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/terminaldispatcher.cc at 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?
>
>
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20180527/b6011a3b/attachment.html