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

[Erik Hons]

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



On Mon, May 28, 2018 at 11:16 AM, Erik Hons <erik.hons at gmail.com> wrote:

> 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/6c6ee8c0/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-support-for-xterm-modifer-key-resource-values.patch
Type: application/octet-stream
Size: 5720 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/mosh-devel/attachments/20180528/6c6ee8c0/attachment-0001.obj