4 ms·

>SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response

>SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response to typing, deleting, and line editing. This seems asinine. If latency is an issue I want to know it, not be fooled into thinking my input is being interpreted correctly by 'predictions'. Does this mean when I hit 'jjjjjll' in vim, I'm going to see this underlined on-screen in mosh in high-latency situations?

shawabawa3 11y ago
> On a bad connection, outstanding predictions are underlined so you won't be misled. Having used it, I found it worked very well and i never had a problem with predictions
willglynn 11y ago
Only if your recent keystrokes have been getting echoed, and if you haven't done something that might disrupt echo. > Predictions are done in epochs: when the user does something that might alter the echo behavior — like hit ESC or carriage return or an up- or down-arrow — Mosh goes back into making background predictions until a prediction from the new batch can be confirmed as correct.
- astazangasta 11y ago
  Yeah, this offends me - I want my terminal to have simple, predictable behavior, not be trying to reason about what the shell process is up to. If it has some predictive model, I have to worry about my predictive model (expectation of what happens when I hit a key) being in conflict.
  - fizzbatter 11y ago
    You really don't have to worry about that, imo. The predictive feature doesn't overlap connectivity issues long enough for you to ever wonder "Am i connected or not"? Not to mention, it shows you in two ways that you have connectivity issues. 1. All echoing prints underlines, so you always know if it's predictive output or not. 2. Any prolonged connectivity issue displays a blue bar at the top of the session, showing how long you've been disconnected for. edit: And of course, you can simply turn off predictive echo if it's a feature you hate. but man oh man, is it something to love, imo.
  - mikeash 11y ago
    As opposed to having your non-predictive model be in conflict, because your connection decided to space out for a minute so you don't see any results from any of your typing?
fizzbatter 11y ago
If that's what you want, then don't use predictive echoing (or w/e it's called exactly). I've been using Mosh for years on spotty connections and this feature alone is an absolute game changer. Sure, when you're trying to `jjjj` and your network hiccups, it may look weird for a moment, but no more weird than not seeing any input imo. And when you're not `jjj`ing, but instead typing in edit mode, you don't notice anything, it's flawless. Also, Mosh shows a blue banner on top if there is prolonged connectivity issues, so it's not like it is tricking you or anything. The feature merely smooths out the UX, and it does so amazingly well.
cyphar 11y ago
I thought that too when I first heard of mosh. But mosh is actually clever about it and it doesn't try to guess what would happen in vim. It usually only does predictions for prompts. In addition, the predictions are very obviously predictions (they're underlined). It's a very useful feature if you're trying to modify a complicated pipeline over a lossy network.

shawabawa3 11y ago

> On a bad connection, outstanding predictions are underlined so you won't be misled. Having used it, I found it worked very well and i never had a problem with predictions

willglynn 11y ago

Only if your recent keystrokes have been getting echoed, and if you haven't done something that might disrupt echo. > Predictions are done in epochs: when the user does something that might alter the echo behavior — like hit ESC or carriage return or an up- or down-arrow — Mosh goes back into making background predictions until a prediction from the new batch can be confirmed as correct.

astazangasta 11y ago
Yeah, this offends me - I want my terminal to have simple, predictable behavior, not be trying to reason about what the shell process is up to. If it has some predictive model, I have to worry about my predictive model (expectation of what happens when I hit a key) being in conflict.
- fizzbatter 11y ago
  You really don't have to worry about that, imo. The predictive feature doesn't overlap connectivity issues long enough for you to ever wonder "Am i connected or not"? Not to mention, it shows you in two ways that you have connectivity issues. 1. All echoing prints underlines, so you always know if it's predictive output or not. 2. Any prolonged connectivity issue displays a blue bar at the top of the session, showing how long you've been disconnected for. edit: And of course, you can simply turn off predictive echo if it's a feature you hate. but man oh man, is it something to love, imo.
- mikeash 11y ago
  As opposed to having your non-predictive model be in conflict, because your connection decided to space out for a minute so you don't see any results from any of your typing?

fizzbatter 11y ago

If that's what you want, then don't use predictive echoing (or w/e it's called exactly). I've been using Mosh for years on spotty connections and this feature alone is an absolute game changer. Sure, when you're trying to `jjjj` and your network hiccups, it may look weird for a moment, but no more weird than not seeing any input imo. And when you're not `jjj`ing, but instead typing in edit mode, you don't notice anything, it's flawless. Also, Mosh shows a blue banner on top if there is prolonged connectivity issues, so it's not like it is tricking you or anything. The feature merely smooths out the UX, and it does so amazingly well.

cyphar 11y ago

I thought that too when I first heard of mosh. But mosh is actually clever about it and it doesn't try to guess what would happen in vim. It usually only does predictions for prompts. In addition, the predictions are very obviously predictions (they're underlined). It's a very useful feature if you're trying to modify a complicated pipeline over a lossy network.