xterm-68.patch.txt

XFree86 3.9Ad/3.3.1z - xterm patch #68 - 1998/3/4 - T.Dickey <dickey@clark.net>
 
This corrects another problem with the logic for highlightColor resource.
As reported by David Dawes:
 
        I've just noticed a problem with with the "inverse" control sequence
        (ESC[7m) with the 3.3.2 xterm.  What it does is sets the background
        black, and the text the usual foreground colour rather than simply
        swapping the foreground/background.
 
This appears to be because when I added logic to check that the highlightColor
was distinct from foreground and background colors, I did not add a further
check to see that it was not black (I would make an explicit check for the
resource not being set, but see nothing definite in the headers that would let
me reference an explicitly-undefined Pixel value, though there are some
implications in xpm.h).  But this should work.
 
--------------------------------------------------------------------------------
 util.c         |    3 ++-
 version.h      |    2 +-
 xterm.log.html |   19 +++++++++++++++++++
 3 files changed, 22 insertions, 2 deletions
--------------------------------------------------------------------------------
Index: util.c
--- xterm-67+/util.c    Mon Feb 23 21:37:53 1998
+++ xterm-68/util.c     Tue Mar  3 06:23:33 1998
@@ -1457,7 +1457,8 @@
 #if OPT_HIGHLIGHT_COLOR
                if (hi_pix != screen->foreground
                 && hi_pix != fg_pix
-                && hi_pix != bg_pix) {
+                && hi_pix != bg_pix
+                && hi_pix != 0) {      /* FIXME: need a reliable undef-Pixel */
                        bg_pix = fg_pix;
                        fg_pix = hi_pix;
                }
Index: version.h
--- xterm-67+/version.h Mon Feb 16 17:12:28 1998
+++ xterm-68/version.h  Tue Mar  3 06:35:56 1998
@@ -6,4 +6,4 @@
  * version of xterm has been built.  The number in parentheses is my patch
  * number (T.Dickey).
  */
-#define XTERM_VERSION "XFree86 3.9Ad(66)"
+#define XTERM_VERSION "XFree86 3.9Ad(68)"
Index: xterm.log.html
--- xterm-67+/xterm.log.html    Mon Feb 23 22:20:44 1998
+++ xterm-68/xterm.log.html     Tue Mar  3 06:53:53 1998
@@ -41,6 +41,7 @@
 xc/programs/Xserver/hw/xfree86).
 
 <UL>
+<LI><A HREF="#xterm_68">Patch #68 - 1998/3/4 - XFree86 3.9Ad and 3.3.1z</A>
 <LI><A HREF="#xterm_67">Patch #67 - 1998/2/23 - XFree86 3.9Ad and 3.3.1e</A>
 <LI><A HREF="#xterm_66">Patch #66 - 1998/2/16 - XFree86 3.9Ad and 3.3.1d</A>
 <LI><A HREF="#xterm_65">Patch #65 - 1998/2/14 - XFree86 3.9Ad and 3.3.1c</A>
@@ -109,6 +110,24 @@
 <LI><A HREF="#xterm_02">Patch #2 - 1996/1/7</A>
 <LI><A HREF="#xterm_01">Patch #1 - 1996/1/6</A>
 </UL>
+
+<H1><A NAME="xterm_68">Patch #68 - 1998/3/4 - XFree86 3.9Ad and 3.3.1z</A></H1>
+
+This corrects another problem with the logic for highlightColor resource.
+As reported by David Dawes:
+<blockquote>
+       I've just noticed a problem with with the "inverse" control sequence
+       (ESC[7m) with the 3.3.2 xterm.  What it does is sets the background
+       black, and the text the usual foreground colour rather than simply
+       swapping the foreground/background.
+
+</blockquote>
+This appears to be because when I added logic to check that the highlightColor
+was distinct from foreground and background colors, I did not add a further
+check to see that it was not black (I would make an explicit check for the
+resource not being set, but see nothing definite in the headers that would let
+me reference an explicitly-undefined Pixel value, though there are some
+implications in xpm.h).  But this should work.
 
 <H1><A NAME="xterm_67">Patch #67 - 1998/2/23 - XFree86 3.9Ad and 3.3.1e</A></H1>