Mechanism to let remote server send messages back to the client

[lilyball]

I would really love a way to let the remote server send short messages back to the client, where mosh can then pass them to an external program. The use-case here is I use mosh to connect to irssi, and I really want some way for irssi to notify me on highlights, but since it's running remotely, it can't do it. I figured Mosh could define some escape sequence that accepts messages up to a specified length (something short but not unreasonably short, like maybe 512 or 1024 bytes), and guarantees delivery (in sequence) to the client, similar to how it handles keyboard events. On the client side, a flag can be used to denote an external program that will be called with each message (either called once per message, or perhaps invoked at connection and messages passed to it over a pipe, using some framing (such as byte count, newline, message, newline).

Using this mechanism, I could then write a script for irssi that prints that escape sequence to the terminal, along with a JSON blob containing information on the highlight, and I could write a program on the local side that displays OS X notifications for the messages.

I could theoretically do this all for an SSH connection, but because of how mosh handles the screen, I can't rely on that sort of thing working for mosh (especially because I don't know how mosh reacts to unknown escapes).

[lilyball]

I wonder if I can re-use some of the existing OSC escapes? The question is whether mosh actually considers any of them to be things it must transmit always, like keyboard, or whether it only sends OSC escapes that it knows how to synchronize with the state synchronization (like window title). Because the latter is not acceptable for notifications. Also, in a quick test, it limits the window title escape to only 255 characters, which is slightly shorter than I'd like for the notification purposes (I'd really like to support the entire length of an IRC message in there, which IIRC is a little over 400 characters usually, and ideally it would have room for a JSON wrapper).

[lilyball]

After testing, mosh does indeed synchronize the current state of the window title, as opposed to just transmitting all the OSC escapes. Not surprising. I'm doubtful at this time that there are any OSC escapes it considers to be must-transmit values.

[rupa]

I don't feel like this is really in scope for mosh, but I'd love to have this feature.

[lilyball]

If all Mosh did was pick some unused OSC sequence and treat it as a must-transmit sequence (and document it), then I could handle the rest with a wrapper program. But I need something that's guaranteed to be delivered.

Although it occurs to me, I also need to be able to punch through tmux with whatever sequence this is. I don't know how tmux handles unknown OSC escapes.

[sunaku]

tmux doesn't care what escape sequences you send, so long as you wrap them properly:

printf "\033Ptmux;\033%s\033\\" your_escape_sequence_here_whatever_it_may_be

[gnachman]

This also affects shell integration in iTerm2 (https://iterm2.com/shell_integration.html).

[greened]

This also affects emacs-libvterm directory tracking (#1122) and probably emacs directory tracking in general. It's not just special/undefined OSCs that should get transmitted. There are many defined OSCs (like OSC 51 in the case of emacs) which should be transmitted.

I think the way emacs and iTerm2 use escape sequences is probably very similar.