On Thursday, October 26, 2023, Phi Debian <phi.deb...@gmail.com> wrote:
> On Wed, Oct 25, 2023 at 5:01 PM Greg Wooledge <g...@wooledge.org> wrote: > > > > > Ahh. That wasn't clear to me. Thanks. > > > > > Ouch got caught the same way. This can be reduced to > > $ clear > $ echo "\e[36;44;4m\nsome colored\ttext with\ttabs\e[m\n" > $ <up><ret> # Recall and run prev command > repeat the later until top lines scroll out. > > I added ;4 in the first \e i.e Underline to show that doing <tab> output is > just a cursor movement (not a char painting) as would do any other cursor > positioning esc seq. > > Doing so we see that on <tab> both the color and the underline are not > decorated, on top lines, this is normal > > When the scroll out occurs, the underline is never painted, as expected, > yet the BG color of the 'tab' is decorated. > > This is because there is a bogus \n right after the SGR sequence > \e[36;44;4m\n this later \n say we open and SGR attribute, and \n will > preserve it on scroll out, BUT colors at not completly SGR as stated here > > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html search for > *"ANSI X3.64-1979"* > > > *When we remove the bogus \n all is normal* > > $ clear > $ echo "\e[36;44;4m\some colored\ttext with\ttabs\e[m\n" > <up><ret> > many time. > > > Generally speaking it is not good to leave an open SGR sequence before a > \n, when emitting SGR before the \n it is wise to have a closing sequence > \n[m\n > I can reproduce this behavior on all the terminals I have access to except xterm on Solaris 10, it never paints the background of a tab, which is at least consistent. I wonder what changed... -- Oğuz