On Thu, 30 Sep 1999 18:59:45 -0500, David DeSimone <[EMAIL PROTECTED]> said:
>If Mutt is printing lots of spaces to the end of the line, why doesn't
>this cut/paste behavior always show up? Why is it only happening when
>color is enabled?
It is probably using an escape sequence (ESC[K) for the case when
there is no color.
>I cannot believe that Slang would really determine on its own, that
>"<space><space><space><space><space><space><space><space>" is more
>efficient than "<esc>[K". Or any screen-management package.
ESC [ K is three characters. Suppose, that only two characters
need to be erased. Then slang would use two spaces instead of the
escape sequence.
>> In fact, until the BCE capability was implemented in the X11R6 xterm
>> (Dickey's version), it was impossible clear to the end of a line in a
>> color other than the default without writing spaces.
>
>But what about when the color chosen is simply "default;default"?
In that case, it would use ESC[K most of the time to erase to the
end of the line, as long as the line is to be cleared in the default
color. Otherwise, it would have to use explicit spaces on a non-BCE
terminal.
>I have noticed that rxvt treats spaces-to-end-of-line as simple a
>newline. I don't like that behavior, because sometimes spaces at the
>end of the line really are important.
And sometimes they are not. There is no black or white answer to
this problem.
[...]
>But then, folks like me, who turn off the alternate screen, can't get
>correct behavior.
As stated above, the correct behavior is context sensitive and
xterm has no way of knowing what that context is.
>Can you supply more information about the BCE capability you mentioned?
>I am running Dickey's xterm, but I suspect that my terminfo might not
>contain all of the information needed to utilize the capability. But
>then, Slang uses termcap.. doesn't it? Hmm...
Slang uses terminfo on systems that support it. Otherwise, it uses
termcap. I suggest that you use the latest 1.3 version of slang.
Previous versions only had limited support for non-BCE terminals. You
may have better luck with the latest version.
Regarding BCE vs non-BCE, here is something that I posted 3 years
ago on the subject. Below, BCE is refered to as the `new color model'
and non-BCE is the `old'.
On 18 Mar 1996 10:38:09 GMT, Pascal A. Dupuis <[EMAIL PROTECTED]>
wrote:
: I tried to play a bit with colors in slrn. But I've come to what I find an
: annoyance : foreground and background apply to text and don't extend to the
: end of the line, which is set to the normal color. To avoid this kind of
: mosaic effect, should it be possible to define windows, in order for exemple
: to have poster name, subject, number of lines, ... with the same background
: color, from the beginning to the end of the line ?
slrn only supports the so-called new color model terminals. The old color
model is brain-dead because it does not permit efficient screen updating.
The basic difference between these models is that the old model uses the
DEFAULT background color for erasing whereas the new model uses the CURRENT
color. For example, to turn a 24x80 display blue using the new model, one
has to simply to send the 9 characters:
ESC [ 4 4 m ESC [ 2 J
where as the old model requires that 24x80=1920 space characters be sent. I
suggest that you use a color terminal that supports the new color-model.
The only terminal for X that I know of that supports this is `rxvt'. I have
heard that the color xterm included in the next release of X will also
support this. In addition to rxvt, new color-model terminals include NSCA
telnet, the Linux console and new DEC terminals.
Terminals which do NOT support it include ansi-xterm, MS-Kermit, screen, as
well as old DEC terminals. Someone told me that ansi-xterm is being
modified to support this model. I have tried to pursuade the MS-Kermit
authors to modify MS-Kermit but they insist upon emulating the flawed
old-model.
