Work around JuiceSSH rendering bug

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 commit is contained in:
John Hood
2017-03-26 21:27:38 -04:00
parent aa74af9a34
commit 2873def506
+3 -3
View File
@@ -386,7 +386,7 @@ bool Display::put_row( bool initialized, FrameState &frame, const Framebuffer &f
frame.append_silent_move( frame_y, frame_x - clear_count ); frame.append_silent_move( frame_y, frame_x - clear_count );
frame.update_rendition( blank_renditions ); frame.update_rendition( blank_renditions );
bool can_use_erase = has_bce || ( frame.current_rendition == initial_rendition() ); bool can_use_erase = has_bce || ( frame.current_rendition == initial_rendition() );
if ( can_use_erase && has_ech ) { if ( can_use_erase && has_ech && clear_count > 4 ) {
snprintf( tmp, 64, "\033[%dX", clear_count ); snprintf( tmp, 64, "\033[%dX", clear_count );
frame.append( tmp ); frame.append( tmp );
} else { } else {
@@ -436,8 +436,8 @@ bool Display::put_row( bool initialized, FrameState &frame, const Framebuffer &f
frame.append_silent_move( frame_y, frame_x - clear_count ); frame.append_silent_move( frame_y, frame_x - clear_count );
frame.update_rendition( blank_renditions ); frame.update_rendition( blank_renditions );
bool can_use_erase = !wrap_this && ( has_bce || ( frame.current_rendition == initial_rendition() ) ); bool can_use_erase = has_bce || ( frame.current_rendition == initial_rendition() );
if ( can_use_erase ) { if ( can_use_erase && !wrap_this ) {
frame.append( "\033[K" ); frame.append( "\033[K" );
} else { } else {
frame.append( clear_count, ' ' ); frame.append( clear_count, ' ' );