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

[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?


On Sun, May 27, 2018 at 9:14 PM, Keith Winstein <keithw at cs.stanford.edu>
wrote:

> 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/20180528/e032dc25/attachment.html