#review - 1 byte at a time seems inefficient... but we don't have a way to peek or put back chars (?)
#todo - timeout - what if terminal doesn't put data on stdin?
#review - what if we slurp in data meant for main loop? Main loop probably needs to detect these responses and store them for lookup *instead* of this handler
#we may still need this handler if such a loop doesn't exist.
#consider \x1b as text on console vs \x1b the character
#review - if we're getting these actual escape characters in line mode.. something is off - let's emit something instead of trying to interpret as a command and failing.
#This tends to happen when some sort of readline not avaialbe ie on unix or mintty in windows
#this only captures leading escape.. as an aid to diagnosis e.g <sp><right-arrow> won't be caught and the user will need to close the right bracket to complete the bogus command
#we may need to think about legitimate raw escapes in commands e.g from pipes or script files, vs via console?
#esc key or ctrl-lb followed by enter
if {$line eq "\x1b"} {
#abort current command
if {$linenum == 0} {
doprompt "E% " {yellow bold}
#screen_last_char_add " " empty empty
} else {
doprompt "\nE% " {yellow bold}
#screen_last_char_add "\n" empty empty ;#add \n to indicate noclearance required
set ::repl::last_repl_char "\n" ;#this is actually the eol from stdin
screen_last_char_add "\n" stdin $line
#consider \x1b as text on console vs \x1b the character
#review - if we're getting these actual escape characters in line mode.. something is off - let's emit something instead of trying to interpret as a command and failing.
#This tends to happen when some sort of readline not avaialbe ie on unix or mintty in windows
#this only captures leading escape.. as an aid to diagnosis e.g <sp><right-arrow> won't be caught and the user will need to close the right bracket to complete the bogus command
#we may need to think about legitimate raw escapes in commands e.g from pipes or script files, vs via console?
