Debian bug 578729 has reappeared.

1. Create a .screenrc file with: defbce on
2. Start xterm (trimSelection must be false; this is the default).
3. Start screen in xterm.
4. Start Mutt with: mutt -F /dev/null -f /dev/null
5. Redisplay the window with C-a C-l (alternatively, create a new window
   with C-a c and go back to the first window with C-a o).
6. Select a blank line with a double-click.
7. Paste the blank line in some editor.

Result: 80 spaces (corresponding to the width of the terminal)
are pasted instead of just a newline character (LF).

The display.c source file still contains "bcechar = mchar_null;"
(which was in the fix for Debian bug 578729). So I suppose that
something else broke.

Hi Vincent,

Can you please try to reproduce this bug with the latest unstable
(5.0.1-2)?

Thanks,
Peter Dey

Control: found -1 4.9.1-3.1
Control: found -1 5.0.1-2
Control: tags -1 - moreinfo

I can reproduce it with both 4.9.1-3.1 and 5.0.1-2.

FYI, I had already reported the same bug earlier in the past
in screen 4.0.3 (2010):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578729

and this was fixed in a 4.1.0 prerelease (2011):

  - Fixes a bug with displaying blank spaces with bce on. (Closes: #578729,
    LP: #702094)

But apparently, the bug reappeared...

Hi Vincent,

I retested this with clean chroots and your mutt/xterm reproduction
steps.

Tested versions:
- 4.1.0~20110819git450e8f3-1
- 4.2.0-1
- 5.0.1-2

Observed behaviour is consistent across all three:
- outer TERM=xterm         : no trailing spaces
- outer TERM=xterm-256color: trailing spaces to full line

So this does not appear to be a regression introduced in screen 4.8.x or
5.x.
It looks like longstanding TERM-dependent behavior, which can appear as
a regression when environments default to xterm-256color.
Somewhere between buster and trixie, the default TERM seems to have
changed from xterm to xterm-256color; making this appear as a
regression.

The fix to resolve #578729 (upstream commit 98bf413) still exists in
screen 5.x.

Given the interplay between screen, xterm, terminfo and mutt, I can't
say which package the bug lies in.

Cheers,
Peter Dey

I've been using TERM=xterm-256color since December 2018, thus before
buster. But this was much after #578729 was closed anyway.

I suppose that only screen, xterm and terminfo settings are involved
by the redisplay (C-a C-l), which is important to trigger the problem.

I forgot that I also tested in GNOME Terminal, also with
TERM=xterm-256color (note that GNOME Terminal does not have its own
terminfo settings; it rather emulates other terminals, like xterm),
and I can reproduce the bug there too. As a double-click selects
only one single space in GNOME Terminal, one needs to triple-click
to see the problem.

Do you think you could write a minimal reproducer in a bash script?
I haven't been able to reproduce the same symptoms anywhere except for
mutt.

along with the release date which includes this change:

commit 86ce25b620c52c9bdea94bf1185a274466f69b80
Author: Amadeusz Sławiński <amade@asmblr.net>
Date:   Fri Jul 7 18:39:34 2017 +0200

    separate handling of 16 color and 256 color escapes

    on xterm
    echo -e "\e[38;5;1mtest\e[1mtest"
    puts both 'test' strings in same color, however in screen, second one is
    bright

    do note that defbce on, may interfere with this

    Bug: 50601
    Signed-off-by: Amadeusz Sławiński <amade@asmblr.net>

only screen.  The checkin comment describes a regression.

along with the release date which includes this change:

commit 86ce25b620c52c9bdea94bf1185a274466f69b80
Author: Amadeusz Sławiński <amade@asmblr.net>
Date:   Fri Jul 7 18:39:34 2017 +0200

    separate handling of 16 color and 256 color escapes

    on xterm
    echo -e "\e[38;5;1mtest\e[1mtest"
    puts both 'test' strings in same color, however in screen, second one is
    bright

    do note that defbce on, may interfere with this

    Bug: 50601
    Signed-off-by: Amadeusz Sławiński <amade@asmblr.net>

only screen.  The checkin comment describes a regression.

I'm wondering what this was supposed to do. Anyway, screen 4.09.01
(at least) is buggy on the term-test.pl testcase found at

https://savannah.gnu.org/bugs/index.php?50601

(I'm still using "defbce on".)

I wanted to say that xterm is involved in the rendering, but it may
not be related to the problem. Concerning Mutt, it is not involved
at all with the redisplay (one can even quit Mutt before doing the
redisplay with C-a C-l... the same problem occurs).

Xterm logging allowed me to find the escape sequences:

  screen sh -c 'printf "\e[40m\e[K\n\e[K\n\e[K\n"; sleep 999'

The 3 lines above the cursor (those generated by "\e[K\n") are
affected: no issues before a redisplay, and after a redisplay
(C-a C-l), sequences of spaces are generated.

  screen sh -c 'printf "\e[40m\e[K\n\e[41m\e[K\n\e[49m\e[K\n"; sleep 999'

This does the following:
  * Set the background to black and erase the line.
  * Set the background to red and erase the line.
  * Set the background to the default and erase the line.

Since bce is on, each line is erase with the chosen background color.

Before redisplay, none of the lines are affected. After redisplay,
the first two lines (those with an explicit background color) are
affected, but not the third one (default background).