[lkml]   [2008]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux 2.6.26 vt back_color_erase

On Friday 2008-10-10 12:49, Alexander V. Lukyanov wrote:

>On Fri, Oct 03, 2008 at 12:11:47PM +0400, Alexander V. Lukyanov wrote:
>> vc->vc_scrl_erase_char was introduced in 2.6.26 for some reason. I beleave
>> this change should be backed out.

There is video_erase_char which contains the background fill and is used
for escape codes such as \e[J and \e[K; scrolling also traditionally used
these, which I consider a visual bug. So scrl_erase_char was introduced
that contains the default color, and which is used for scrolling
(the complement of erase ops like J and K).

>I think that the test cases Jan provided could be fixed by temporary
>changing erase char when doing cr/lf when vc->vc_need_wrap is true.
>There is no need to change erase character for all scrolling operations.

Only in the latter of the following two,
vc_need_wrap will be set to 1 during the course of printing it to
the console, but the background fill issue happens with both
test strings.

>> Current linux kernel has broken bce semantics. Now insert_line and
>> delete_line clear the new lines with default color and not with the
>> current background as they should, and what is expected by ncurses.

I beg to differ. The Linux VT now does exactly what an xterm does,
namely that newly inserted lines do not get filled with the
background color. And I consider that the right thing, because it
does not leave ugly color patches lying on your screen when `ls -l`
overruns the screen width, and someone decided to use a background
color for his filenames.

ncurses should not expect anything. Except what is in terminfo.
Do we need a terminfo db update for the "linux" term?

 \ /
  Last update: 2008-10-10 19:25    [W:0.088 / U:3.912 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site