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

[Keith Winstein]

Hi Erik,

It looks reasonable to me -- please feel free to submit a pull request on
GitHub. One question will be, how does mosh-client know it's okay to send
these sequences to the local terminal (e.g. are they in the termios entry
or something), or if it's not possible to know, are we pretty sure nothing
bad comes from sending them to some other type of local terminal?

-Keith

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

> 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/20180603/39a0967a/attachment.html