<div dir="ltr">Hey Keith,<div><br></div><div>Thanks for writing back! I think my situation is different than the bug you linked to. <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Let me see if I have this right:<span> </span></span>
</div><div><br></div><div>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. </div><div><br></div><div>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!</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Does that all make sense?</div><div><br></div><div>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? </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 27, 2018 at 9:14 PM, Keith Winstein <span dir="ltr"><<a href="mailto:keithw@cs.stanford.edu" target="_blank">keithw@cs.stanford.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Erik,<div><br></div><div>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.</div><div><br></div><div><a href="https://github.com/mobile-shell/mosh/issues/178" target="_blank">https://github.com/mobile-<wbr>shell/mosh/issues/178</a><br></div><div><br></div><div>Maybe mintty and Ctrl-Backspace are in the same boat? If you want to help us fix this bug overall, that would be awesome.</div><div><br></div><div>For the specific question, you basically have two options:</div><div><br></div><div>(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.</div><div><br></div><div>(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/<wbr>terminaluserinput.cc .</div><div><br></div><div>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.</div><div><br></div><div>-Keith</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Sat, May 26, 2018 at 1:18 PM, Erik Hons <span dir="ltr"><<a href="mailto:erik.hons@gmail.com" target="_blank">erik.hons@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div>I'm trying to make emacs work well inside mintty/mosh. I'd like mintty</div><div>to send an alternate escape sequence for "C-Backspace" than the</div><div>default (which is "C-_"). There is an xterm sequence for this --</div><div>"\e[>4;1m" -- which sets the "modifyOtherKeys" resource. Emacs sends</div><div>that sequence on startup. When using ssh for remoting, the sequence is</div><div>passed to the client side, mintty sees it, and implements the desired</div><div>behavior.</div><div><br></div><div>The mosh terminal emulator appears to discard the sequence. There is</div><div>no matching function in terminal/terminalfunctions.cc defined for it,</div><div>so the dispatch process hits the "unknown function" condition in</div><div>terminal/terminaldispatcher.cc<wbr>@226 (Dispatcher::dispatch()).</div><div><br></div><div>As an experiment, I've added a terminal function for "\e[>4;1m" and</div><div>confirmed that it sees the sequence when emacs sends it. I'm stuck on</div><div>what to do next.</div><div><br></div><div>It looks like I need to add something to Terminal::DrawState, then in</div><div>Display::new_frame() look for that member and call</div><div>frame.append("\e[>4;1m"); That's how the "mouse_reporting_mode" and</div><div>similar settings are handled.</div><div><br></div><div>But this might bring up a bigger question: How should the mosh</div><div>terminal emulator interact with the client side terminal emulator? I</div><div>can add support for this specific sequence, but maybe something more</div><div>general is warranted.</div><div><br></div><div>Any advice?</div><div><br></div></div></div>
<br></div></div>______________________________<wbr>_________________<br>
mosh-devel mailing list<br>
<a href="mailto:mosh-devel@mit.edu" target="_blank">mosh-devel@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/mosh-devel" rel="noreferrer" target="_blank">http://mailman.mit.edu/mailman<wbr>/listinfo/mosh-devel</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>