Created attachment 961602 [details] screenshot displaying bug Description of problem: gnome-terminal does not correctly line wraps in special case where colored dot is near the line wrap point. Version-Release number of selected component (if applicable): gnome-terminal.x86_64 3.14.2-1.fc21 How reproducible: Always. Steps to Reproduce: 1. open terminal 2. enter command: echo xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxA.YYYY | grep -E "\.YYY" where number of 'x' is the terminal screen width minus one. Actual results: One character is truncated from the output. Expected results: Whole line is displayed, including 'A'.
This is not specific to gnome-terminal, xterm does the same. See http://savannah.gnu.org/bugs/?36831 for discussion; I use GREP_COLORS=ne as a workaround. Summary: grep outputs \e[K after changing color. This is a workaround so that if a non-default background color is in effect when a line wrap occurs and the terminal scrolls, then the new line doesn't get fully painted with that background color (that is, to work around the braindamagad "bce" [background color erase] feature of pretty much all the terminals). It's an interesting question whether VTE (gnome-terminal) should intentionally deviate from xterm here. We should study what konsole does, it doesn't suffer from this bug, yet passes vttest's 1st test including the really tricky case where lowercase letters are printed in the rightmost column. I believe the really correct solution would be: 1. Modify ncurses/slang/etc to make no assumptions about the color of the new row appearing when the terminal contents scroll. The presence or absence of the "bce" feature should only describe what happens when erasing within an existing line. 2. Wait for a couple of years until these libraries are widely deployed. 3. Modify grep not to print \e[K, as this workaround is no longer necessary then. 4. Modify terminal emulators to ditch the braindamaged bce feature. Utilities such as "ls -l" when using a background color (e.g. dangling symlink) would be grateful for this. Until this happens, the following partial fixes might be desirable: - Patch grep to default to enable the "ne" mode by default. Having the nondefault background color fill an entire line is ugly but still much less worse than a letter getting dropped. - Figure out what konsole does here and modify VTE to do that.
To clarify: In my opinion, bce is cool and useful when being used within a line, e.g. by \e[K or \e[P. Then it's reasonable to fill the cleared cells with the currently active background color. (If you've ever seen the top cyan bar of Midnight Commander not to extend fully to the right, like here: https://www.midnight-commander.org/attachment/ticket/2479/AfterView.jpg then it is most likely caused by an incorrect TERM setting: the screen library expects a \e[K to use the background color because it sees the bce capability (like TERM=xterm or TERM=screen-bce), whereas the actual terminal emulator does not support it (e.g. screen or tmux, which would expect TERM=screen instead which does not contain bce).) The only thing I'd like to change is that a line newly appearing at the bottom due to scrolling should never receive the active background color, it should receive the default one instead. Currently, any simple utility printing something with a background color (such as "ls -l danglingsymlink") behaves unexpected if the text wraps within the special background color AND this wrapping causes the contents to scroll. This behavior makes no sense whatsoever, and makes it practically impossible for utilities to print the right thing. Unfortunately the \e[K workaround grep tried to introduce for this problem causes more harm than good.
Upstreamed: https://bugzilla.gnome.org/show_bug.cgi?id=740789
Modified the behavior in mainstream vte git.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.