On MU*s that use ANSI codes (which get interpreted by tf) to set a
background color other than the default (white on xterms, black on
console). The display gets messed up, specifically when a line of text
gets sent that portion of the screen will get displayed as specified;
however, the portion from the end of line to the right edge will get
colored the default color not the background color specified by the
server. I suspect this is due to outputing the value of "end_color" prior
to outputing newlines, but I do not know where this occurs.

This is partially caused by the line
"if (current) attributes_off(current);" at the end of hwrite(). Removing
the line doesn't solve the issue because it means tf loses track of the
current terminal state. Changing the variable "current" to be static
didn't appear to completely address the issue either.

This is not what I consider an elegant solution to the problem, but it
does work, and should keep the impact to a minimum.

When visual mode is off, this simply fixes the characteristic I was
seeing as a problem. This has the side effect of making the "-- more --"
prompt echo what the current color is (inverted so it should still stand
out), as well as making whatever text is being typed in be the current
color.

I'm not sure how this should be changed when visual mode is on. I've
taken the conservative approach and this /should/ have no effect when
visual mode is on.

On MU*s that do not use ANSI codes this patch should have no effect
whatsoever (please note the /should/ though).

-----8<-----------------------------------------------------------8<-----
--- output.c.0  Sat Mar  6 14:43:25 1999
+++ output.c    Sun Dec  1 17:11:51 2002
@@ -191,7 +191,7 @@
 /* Others */

 #define Wrap (wrapsize ? wrapsize : columns)
-#define more_attrs (F_BOLD | F_REVERSE)
+#define MORE_ATTRS (F_BOLD | F_REVERSE)
 #define moremin 1
 #define morewait 50

@@ -388,7 +388,7 @@
     ystatus = lines - isize;

     prompt = fgprompt();
-    (moreprompt = new_aline("--More--", more_attrs))->links++;
+    (moreprompt = new_aline("--More--", MORE_ATTRS))->links++;

     init_term();
     ch_hiliteattr();
@@ -1617,8 +1617,8 @@
     Aline *line;
     int start, end;
 {
+    static attr_t current = 0;
     attr_t attrs = line->attrs & F_HWRITE;
-    attr_t current = 0;
     attr_t new;
     int i, ctrl;
     int col = 0;
@@ -1635,8 +1635,11 @@

     cx += end - start;

-    if (!line->partials && hilite && attrs)
-        attributes_on(current = attrs);
+    if (screen_mode >= 1) {
+        if (!line->partials && hilite && attrs)
+            attributes_on(current = attrs);
+    }

     for (i = start; i < end; ++i) {
         new = attrs;
@@ -1665,7 +1668,7 @@
             col++;
         }
     }
-    if (current) attributes_off(current);
+    if (screen_mode >= 1) {
+        if (current) attributes_off(current);
+        current = 0;
+    } else moreprompt->attrs = current ^ MORE_ATTRS;
 }

 void reset_outcount()
-----8<-----------------------------------------------------------8<-----

A few notes on what I mean by inelegant:

I think the real solution is along the lines of making crnl() a function
on all platforms (currently only on OS/2 is it a function, others it is
simply a macro). When a newline is emitted this function should retrieve
the current drawing state (notably the background color) call
attributes_on() emit the newline, then call attributes_off().

The question is where to retrieve the current drawing state from? Another
problem is that in visual mode crnl() isn't used at all, scrolling is
used (but it comes to the same issue, turn the background color on prior
to scrolling).


When it comes down to it my patch effectively does the above by leaving
the terminal in the correct state to draw at all times. The problem is
that if visual mode is on, we don't know what will be drawn next so
leaving the terminal in the text drawing state is dangerous (and the
patch avoids this by leaving the terminal in the default state).