Instant response to readline-ish line editing

[crishoj]

Mosh currently provides instant response to basic line editing: Typing and moving the cursor using the arrow keys. This feature is a great productivity-enhancer on high-latency links.

However, as soon as some more advanced line-editing is attempted, the predictive model gives up, and Mosh will wait for the server response before regaining the instant responsiveness.

Examples of commonly used line-editing that is not supported include:

• moving the cursor backwards by a whole word (using meta+b)
• erasing a whole word backwards (using meta+backspace)
• transposing characters or words (using ctrl+t and meta+t)

This is all readline-ish behaviour. Granted, not all programs are readline-based. Yet, it seems to be a fairly safe assumption that readline-ish behaviour is expected when any of the keystrokes given above are detected.

Wouldn't it be neat if mosh employed readline locally to guess the outcome of these line-editing operations?

[normanr]

I noticed this week that ctrl+left and ctrl+right are also not emulated :-(

[crishoj]

@keithw, would you have any objections to a patch adding support for the above readline-ish behavior?

[cgull]

There's problems both with input and prediction that make this non-trivial:

• When we see ANSI cursor-movement escape sequences (from arrow keys) on input, we can be pretty sure that the cursor's being moved. Other incoming keyboard sequences vary between apps and by context. Esc-A does very different things in vi and emacs.
• This is, after all, prediction, and for word- or line-oriented keyboard commands, mosh would have to guess where the application thinks the word or line begins or ends.

@crishoj, if you have a patch that can get this mostly right, I think we'd be interested. The nice thing about prediction is that it only has to be mostly right-- it only needs to predict well enough/often enough that users get some benefit, and any bad predictions it makes are cleaned up by updates from the server.