[konsole] [Bug 399615] Mishandling \b at the right margin

[Egmont Koblinger]

https://bugs.kde.org/show_bug.cgi?id=399615

--- Comment #6 from Egmont Koblinger <egmont at 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 the assignee for the bug.