Work around JuiceSSH rendering bug #867
Conversation
JuiceSSH apparently has a bug where ECH for one character (ESC [ 1 X) does not actually erase the character, in its code that receives and interprets Mosh state updates. This was hidden before because Mosh <= 1.2.5 never sent this sequence, it sent ESC [ X instead as an optimization. Do the better optimization of sending spaces for short sequences of blanks instead.
|
It's been a while since I had this swapped in, but my recollection is that we always want to use ECH on systems that support it, even for short runs of blank cells, because there's a semantic difference (for copy-and-paste purposes) between overwriting a cell with a space character and erasing it. You may have more recent state though... |
|
This only affects what we do for blanks between two printing characters, not at the end of the line. Is ECH important in the middle of a line too? |
|
I don't know, to be honest, although I think you're right that it's fine within a line. |
|
Ah, comment confusion here. I think @keithw and I agree that ECH is unimportant mid-line, though. |
|
looking forward to this fix! this has irritated me for a while. anything security-related preventing this from being merged into the nightlies? |
|
Pulled. No, there wasn't anything security related stopping me, merely inattention and lack of focus on Mosh-- I've not been my best lately. |
JuiceSSH apparently has a bug where ECH for one character (ESC [ 1 X) does
not actually erase the character, in its code that receives and interprets
Mosh state updates. This was hidden before because Mosh <= 1.2.5 never sent
this sequence, it sent ESC [ X instead as an optimization.
Do the better optimization of sending spaces for short sequences of blanks
instead.
This appears to fix #846.