Terminal: Line feed violates ANSI color attributes

[LekKit]

Basically, if \n is used when ANSI color attribute is applied, it should not fill the rest of the line with that color. Haiku Terminal does this, however, and this subtly breaks some of the TUI applications rendering.

On a compliant terminal, \n should introduce a new line at the bottom of the screen instead.

Example with htop:

How it should render:

Reproducible with

$ printf "\n\x1b[41mLine is partially red\nWhole row is red\x1b[0m\n\n"

The output should speak for itself: On a compliant terminal, the first row should reset to default color when the line ends, and the next one will be completely filled with red color. With Haiku Terminal though, the opposite happens.

[jessicah]

The "whole row is red" makes zero sense to me, as the attributes are reset _before_ the newline.

Saying that, I have found where the problem is occurring: ​https://github.com/haiku/haiku/blob/master/src/apps/terminal/TermView.cpp#L1370-L1397, in particular:

if (attr.IsBackSet())
    rgb_back = attr.BackgroundColor(fTextBuffer->Palette());

Overall, it's taking the attributes of the previous character, or the current line, which I think is erroneous behaviour. But I need to investigate the "whole row is red" behaviour with other terminal implementations before committing to a fix.

Also, can I get a copy of the htop binary used? Should be small enough to attach to this ticket.

[X512]

Replying to jessicah:

Also, can I get a copy of the htop binary used? Should be small enough to attach to this ticket.

According to screenshot, it is probably Linux binary inside headless RISC-V virtual machine.

[pulkomandy]

The behavior of Haiku's terminal seems logical to me. Could very well be htop trying to workaround a bug due to the wrong TERM value being set or an out-of tync termcap/terminfo database?

[jessicah]

Terminals I've tested thus far, the first line is always only the text portion has the red background. For the second line, behaviour varies within the same terminal. It's honestly kind of bizarre, but generally it's only the text that's red, sometimes it's the whole line, but perhaps after it's gotten itself confused. So I'll address the first-line issue, as that definitely seems wrong. For a whole line, should be using the erase line commands, e.g. \x1b[0K, so using that for testing my fix :-)

[LekKit]

Replying to pulkomandy:

The behavior of Haiku's terminal seems logical to me. Could very well be htop trying to workaround a bug due to the wrong TERM value being set or an out-of tync termcap/terminfo database?

I tried TERM=xterm, TERM=xterm-256color, TERM=linux. No difference.

The termcap/terminfo inside the guest is up to date.

Reproducer script exactly captures what it is doing, I've already dumped what htop outputs when this misrendering occurs.

[LekKit]

Replying to jessicah:

For the second line, behaviour varies within the same terminal.

Sometimes the shell erases last line, etc. I am specifically injecting a bunch of \n therefore.

Anyways htop only cares about the "first line" apparently and I'm not forcing you to mimic "second line" behavior if it is non-standard or undefined behavior. Sorry for any confusion caused. I just tested and every other xterm-like or linux-like terminal exhibits such behavior.

[jessicah]

No, it's fine, I've installed xterm to observe its behaviour, and then going from there. I just haven't found a good way to get BCE to behave correctly in all circumstances yet.