This patch may have performance problems due to the use of XQueryColor in a loop. A better solution would be to use XQueryColors do get the entire map at once.
I've done a little more work on this. I converted it to XQueryColors which seems to work okay.
However, on a 16-bit or deeper display, the call takes forever. There just doesn't seem to be a way to look through the color map efficiently. A simple fix only does the lookups in 8-bit mode under the assumption that in 16-bit mode the requested colors will be available.
Additionally, by cycling through the colormap, there seems to be no way to check if the candidate color is read-only or read-write, or even valid at all! It may be possible to recycle a writable color owned by another app, which would produce the wrong results.
Modulo these two things, it does seem to be a net gain, however.
New version of patch submitted. It works with the new best-visual feature, and more importantly, it legally acquires the close-enough color via XAllocColor.
To test it out, use a 256-color X server, startup Netscape first (which swallows all colors), and then try syntax highlighting a file.
Fix committed: highlight.c 1.9
Built and tested just fine on OSF and SGI.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.