[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: screen vertical split speed vs dvtm
From: |
Chris Jones |
Subject: |
Re: screen vertical split speed vs dvtm |
Date: |
Sun, 10 Jan 2010 11:19:32 -0500 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Thu, Dec 24, 2009 at 03:37:04PM EST, Sadrul Habib Chowdhury wrote:
[..]
> Yes! I could reproduce the problem as well!
>
> I have checked in a fix (a6eea7b4d). Please try it and let me know how
> it works. Thanks for the report.
Hello Sadrul,
It's been over a couple of weeks, and here's what I observe with the
version of GNU/screen that I downloaded from the git repository:
1. the mutt help/status lines at the top & bottom of the screen are not
redrawn correctly when changing screens.
2. various issues with ELinks: random display of spurious characters,
flickering, & tearing.
Context:
-------
1. xterm with 256 colors enabled and a black background
2. UTF-8 locale
3. GNU/unifont or terminus
4. bce set or unset - see below.
Scenarios:
---------
1. mutt displays a 'quick help' bar at the top of the screen and a
status line at the bottom of the screen. Both have their background
set to a color that differs from the remainder of the screen.
The problems with mutt were observed with 'bce' set to 'on' and
'term' set to 'screen-256color-bce'.
With the new version, either or both of these lines appear truncated
in the sense that their rightmost part is set to the background color
of the xterm. This affects a random number of cells that range from
just a few to more than half the width of the display. The loss of
background color does not appear to be directly related to the
presence or absence of text in the foreground. This happens every
time I navigate between mutt's different screens or when I switch
back and forth between mutt and an application running in another
screen window.
Both lines are redrawn correctly when I issue a CTRL-L and are again
randomly truncated as soon as I repeat the above.
This does not happen when 'bce' is set to 'off' and 'term' set to
'screen-256color'. But, as I will describe shortly, these settings
cause other problems with the ELinks web browser.
2. ELinks lets you specify the background & foreground colors at the
application level, regardless of the color settings of the underlying
terminal. I use something that resembles Netscape's default colors.
The following was observed with 'bce' set to 'off' and 'term' set to
'screen-256color'.
- When following a link, the display flickers briefly, showing a few
horizontal black lines (the background color of my xterm).
- There are spurious characters in random locations of the display,
pretty much anything printable, alpha, punctuation, line-drawing
characters.. Sometimes, but no always, the spurious characters are
repeats of the last character of a preceding line. These artifacts
are visible on all web pages, regardless of the language, English,
Western European, CJK.. and with either of the fonts that I use.
- A CTRL-L temporarily removes the artifacts but causes a number of
lines of the display to be randomly truncated, with the light
background not quite making it to the end of the line. This results
in a jagged effect where a few columns' worth of the black
background of the xterm show through alongside the right edge of
the display. Navigating to a new page removes the black marks, but
causes the reappearance of the spurious characters.
- If I set 'bce' back to 'on' and bounce screen, I do not see any
random artifacts, only the flickering black lines when I navigate
to a different web page.
Notes:
-----
1. I ran the same tests with the debian lenny version (4.0.3-11+lenny1)
of screen with 'bce' set to 'on' and I was unable to recreate any of
the above problems.
2. I run four similar programs in the same screen instance: Vim, slrn,
weechat-curses, and cgdb. All four have 'bars' of one form or another
at the top & bottom of the screen. Apart from some occasional
flickering in the areas were the background is set to a different
color than the xterm's, I have not observed any redrawing issues with
these applications.
Thanks,
CJ
- Re: screen vertical split speed vs dvtm,
Chris Jones <=