Re: linux 2.6.26 vt back_color_erase

[Jan Engelhardt]

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,
	\e[44mfoo\n\e[42mbar
and
	\e[44moverlylonglinemorethan80charsorso\e[42mbar
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/