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.h...@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 <kei...@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.h...@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@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@mit.edu >>> http://mailman.mit.edu/mailman/listinfo/mosh-devel >>> >>> >> >
0001-Add-support-for-xterm-modifer-key-resource-values.patch
Description: Binary data
_______________________________________________ mosh-devel mailing list mosh-devel@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-devel
