https://bugs.kde.org/show_bug.cgi?id=399615
--- Comment #6 from Egmont Koblinger <egm...@gmail.com> --- > Good luck with that backward compatibility head in the sand. In my universe, keeping an eye on not breaking the look of ncurses apps doesn't qualify as putting one's head in the sand. > If I use my keyboard to do the same I will get the 80th zero removed. No. In cooked mode (e.g. "cat") you get the exact same behavior as with printf. In raw mode (e.g. "bash") you might press the backspace key, but the shell probably emits totally different sequences towards the emulator. (The cursor is already elsewhere after typing the last letter of a line.) > 40% of modern emulators do the right thing. Old gnome terminal 2.9.3 was ok > too. "the right thing" and "ok" according to your (and my) personal taste. But also according to the terminal emulator specs? Let's try to be more constructive, shall we? There's an ncurses test app attached to the VTE bug I linked earlier (731155). Out of the 5 emulators I could try where printf works as you expect, pterm and kitty fail to render the desired string "50%". What's interesting and surprising: the remaining three (urxvt, screen and tmux) behave at printf as you expect, while also rendering the ncurses app correctly. How do they do this? A bit of investigation seems to reveal that they implement two possible modes: - If the 80th character is printed with autowrapping being turned on (the default mode, "\e[?7h") then a subsequent backspace behaves in your preferred way. I think it just resets the "pending wrap" flag, but leaves the cursor at the 80th position. - If the 80th character is printed with autowrapping being turned off ("\e[?7l", this is what ncurses switches to for this character) then a subsequent backspace moves back the cursor to column 79. Not sure if this is well thought out intentional design (or intentional workaround for the crazy situation we're in) in these apps, or just an accidental side effect of not setting the "pending wrap" flag at all in no-autowrap mode. We could perhaps consult the source code of these software to figure this out. Also not sure if this behavior is correct or not according to ECMA or any other standard. I also cannot find this dual behavior mentioned in the link you posted in your latest comment. urxvt, screen and tmux can backspace correctly across a linebreak in cooked mode (e.g. "cat"). Technically this requires this current issue to be addressed, plus reverse wraparound (at least across soft breaks). Maybe with this dual behavior these emulators found the way to implement this, while not breaking ncurses. Or maybe that's how it's all documented, and is exactly why ncurses switches off autowrapping for the last character. I'd love to have further information on how much this is considered the designed correct behavior, or accidental correct behavior, or a terrible workaround hack, or what exactly. -- You are receiving this mail because: You are watching all bug changes.