Created attachment 114548 [details] bce konsole background repeat when scrolling Hi, It seems than Konsole suffer from the same behavior that VTE terminals had been when they introduced a bug in BCE feature to cover others behaviors relate to this feature and corrected since that. The background is repeated on the whole next line if the line doesn't fit into the terminal and insert a implicit new line. It is exactly the same case as describe in this VTE bug report: https://bugzilla.gnome.org/show_bug.cgi?id=754596 A Konsole user seems impacted by this too: https://www.reddit.com/r/linux/comments/7ojwo9/pureline_a_pure_bash_powerline_prompt_simple_but/dsbe4x5 I could reproduce easily this bug by : - having a PS1 with colors: PS1='\[\e[0;30m\]\[\e[43m\]\u@\h \w \$:\[$(tput sgr0)\] ' - reduce the terminal to his minimal width - entering into a deep directory to have the PS1 too long to fit only into one line - make the terminal scrolling by hit "enter" a few times And you will see something like in the attachement. Regards,
Confirmed with konsole from git master. However this is just applications or scripts not putting in a reset \e[0m type character in right?
IMO it is not related. In the example provided, there is a reset sequence at the end of the prompt.
Confirmed.
UP. I have a related bug so instead of opening a new one, I'll try updating it to give it visibility. And I think they have the same origin. To me the bug lies in the calculations of the prompt size as it incorporates control characters which should not be taken into account. So, the way to reproduce it is way simpler than in the original submission: Step one: create a color prompt such as: > PS1='${debian_chroot:+($debian_chroot)}\033[93m\u@\h:\w\033[0m > ' Step two: trigger a bug. press page up to call last cmd in history. Then press End. This step is not necessary but it makes the bug occur 100% of times. Press Home to reach beginning of line. It doesnt. Press End to reach end of line. It goes past that. Note that in both cases (beginning & end of line), the offset is 9 characters, which corresponds to the number of invisible chars in var PS1, with \033 being 1 char. Other side effect : overwriting current line instead of creating a new one when command longer than konsole width. Fiddling with konsole window width shorter than the current command does strange things to the cursor position.
(In reply to Per Drive from comment #4) > UP. > I have a related bug so instead of opening a new one, I'll try updating it > to give it visibility. And I think they have the same origin. > > To me the bug lies in the calculations of the prompt size as it incorporates > control characters which should not be taken into account. > > So, the way to reproduce it is way simpler than in the original submission: > > Step one: create a color prompt such as: > > PS1='${debian_chroot:+($debian_chroot)}\033[93m\u@\h:\w\033[0m > ' Terminal control sequences in PS1 should be enclosed between \[ and \], as in: PS1='${debian_chroot:+($debian_chroot)}\[\033[93m\]\u@\h:\w\[\033[0m\] > ' so bash can keep a correct idea of where the cursor is. See https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Controlling-the-Prompt
Sorry for my "bug"; Thank you for the explanation and link.