Hi Nicholas, Nicholas Marriott wrote on Fri, May 19, 2017 at 11:46:52PM +0100: > On Fri, May 19, 2017 at 10:23:08PM +0200, Ingo Schwarze wrote:
>> What matters most is that sending an incomplete character >> followed by U+0008 (ASCII BACKSPACE) is a no-op, both in the sense >> that it doesn't change the line being edited and that it doesn't >> change the display. All terminals you mentioned seem to conform >> to that according to my testing, except tmux. > They don't all do the same thing for me. I am doing this, the same as > ksh does: > > printf 'a\010\342a\010\010\342\211a\010\010\342\211\240a\010\n' > > And the terminals behave differently. Hmmm. My testing must have been off. xterm and urxvt behave the way ksh expects (printing the not equal sign followed by the letter a), but you are right, gnome-terminal and konsole differ. For those two, "printf '\342\211\n'" results in *two* replacement characters, and hence your test sequence above ends up with one remaining replacement character before the not equal sign. So you are right, the shell should try to avoid sending invalid intermediate states when it can, that will make the system more robust. Anton has a candidate diff for ksh/emacs.c now, but review and testing are not finished yet. Yours, Ingo
