Re: BUG: Colorize background of whitespace
On Thursday, October 26, 2023, Phi Debian wrote: > On Wed, Oct 25, 2023 at 5:01 PM Greg Wooledge 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" > $ # 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 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 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" > > 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
Re: BUG: Colorize background of whitespace
On Wed, Oct 25, 2023 at 5:01 PM Greg Wooledge 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" $ # 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 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 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" 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
Re: BUG: Colorize background of whitespace
On Wed, Oct 25, 2023 at 02:48:20PM +, David wrote: > On Wed, 25 Oct 2023 at 11:51, Greg Wooledge wrote: > > On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote: > > > Repeat-By: > > > run the following command line: > > > clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n' > > > Play with the parameter to seq, to keep the line within the first screen > > > or move it offscreen. > The bug being reported is that the '\t' characters have a black background > if the 'seq' argument is low enough that its lines 1 and 2 remain > visible when run. > But if the 'seq' argument is changed to be bigger, so that (at least) > lines 1 and 2 both > scroll off the top of the terminal window so that they are not visible, then > the > '\t' characters then get the expected blue background. Ahh. That wasn't clear to me. Thanks. In an 80x24 rxvt-unicode or xterm terminal, "seq 22" shows the reported problem, and "seq 23" does not.
Re: BUG: Colorize background of whitespace
On 10/25/23 10:48 AM, David wrote: The bug being reported is that the '\t' characters have a black background if the 'seq' argument is low enough that its lines 1 and 2 remain visible when run. Bash and readline don't do anything with terminal foreground colors and background colors except under certain circumstances like bracketed-paste. If you're pasting the above command into the terminal, that pasted text will be colored according to active-region-start-color and active-region-end-color (bash-5.2) or terminal standout mode (bash-5.1). Otherwise, readline redisplay just outputs terminal sequences to move the cursor and the characters in the line. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: BUG: Colorize background of whitespace
On Wed, 25 Oct 2023 at 11:51, Greg Wooledge wrote: > On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote: > > Description: > > The initial bash background is hardcoded to some default (e.g. black) and > > cannot be colorized by printing "transparent" tabs/newlines with > > ANSI-ESC-codes. > > Only after a vertical scrollbar appears, the whitespace beyond the window > > hight will get the proper background color. > > Terminals have colors (foreground and background). Bash does not. Bash > is just a command shell. > > > Repeat-By: > > run the following command line: > > clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n' > > Play with the parameter to seq, to keep the line within the first screen or > > move it offscreen. > > > > Reproduced in: > > - in Konsole on Kubuntu 23.04 > > - in the git bash for windows mintty 3.6.1 > > - in WSL cmd window on Windows 11 > > I ran this command in xterm (version 379) and rxvt-unicode (9.30) on > Debian, but I'm not sure what I'm supposed to be seeing. The bug being reported is that the '\t' characters have a black background if the 'seq' argument is low enough that its lines 1 and 2 remain visible when run. But if the 'seq' argument is changed to be bigger, so that (at least) lines 1 and 2 both scroll off the top of the terminal window so that they are not visible, then the '\t' characters then get the expected blue background. I see this in Debian 11, both in 'lxterminal' under LXDE, and in the virtual consoles, [david@kablamm ~]$ echo $BASH_VERSION 5.1.4(1)-release [david@kablamm ~]$ cat /etc/debian_version 11.8
Re: BUG: Colorize background of whitespace
On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote: > Description: > The initial bash background is hardcoded to some default (e.g. black) and > cannot be colorized by printing "transparent" tabs/newlines with > ANSI-ESC-codes. > Only after a vertical scrollbar appears, the whitespace beyond the window > hight will get the proper background color. Terminals have colors (foreground and background). Bash does not. Bash is just a command shell. > Repeat-By: > run the following command line: > clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n' > Play with the parameter to seq, to keep the line within the first screen or > move it offscreen. > > Reproduced in: > - in Konsole on Kubuntu 23.04 > - in the git bash for windows mintty 3.6.1 > - in WSL cmd window on Windows 11 I ran this command in xterm (version 379) and rxvt-unicode (9.30) on Debian, but I'm not sure what I'm supposed to be seeing. In my case, the terminals are 80x24, and xterm has a default black background, while rxvt has a default white background. In both cases, the expected rows of numbers are printed by seq, and then there's a blank line, and then there's a line of dark blue background which extends all the way across the terminal, containing "some colored" and "text with" and "tabs" in a greenish foreground color. Hitting Enter to scroll the text upward doesn't do anything surprising, and neither does scrolling the terminal with Shift-PageUp or with the mouse. What are *you* seeing which surprises you? In any case, this has nothing to do with bash. It's strictly a terminal issue, whatever the issue may be.
Re: BUG: Colorize background of whitespace
On Wed, Oct 25, 2023 at 11:09 AM Holger Klene wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto > -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security > -Wall > uname output: Linux BX-NB-015 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri > Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > Bash Version: 5.1 > Patch Level: 16 > Release Status: release > > Description: > The initial bash background is hardcoded to some default (e.g. black) and > cannot be colorized by printing "transparent" tabs/newlines with > ANSI-ESC-codes. > Only after a vertical scrollbar appears, the whitespace beyond the window > hight will get the proper background color. > > Repeat-By: > run the following command line: > clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n' > Play with the parameter to seq, to keep the line within the first screen > or move it offscreen. > > Reproduced in: > - in Konsole on Kubuntu 23.04 > - in the git bash for windows mintty 3.6.1 > - in WSL cmd window on Windows 11 > > I guess this is the way terminal emulator works, and I guess as well they are doing what real terminals use to do, though I have no such term at hand to prove :-) Worth to consider $ clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n' | expand
BUG: Colorize background of whitespace
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux BX-NB-015 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release Description: The initial bash background is hardcoded to some default (e.g. black) and cannot be colorized by printing "transparent" tabs/newlines with ANSI-ESC-codes. Only after a vertical scrollbar appears, the whitespace beyond the window hight will get the proper background color. Repeat-By: run the following command line: clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n' Play with the parameter to seq, to keep the line within the first screen or move it offscreen. Reproduced in: - in Konsole on Kubuntu 23.04 - in the git bash for windows mintty 3.6.1 - in WSL cmd window on Windows 11
