From what I can tell, it happens when you move between a bold and non-bold
element. Here is how I reproduced it:

1. Start gedit
2. Go to edit->preferences->Syntax Highlighting
3. Select a highlighting mode of XML (the initial selection is a bold type)
4. Move freely between the "Attributes" and "Entity" list entries; note the lack
of confusion
5. Move between one of the two bold entries (it doesn't matter which) and one of
the non-bold entries. Then move back to the bold entry you were just on, and
back again to the same non-bold entry. (I went "Entity", "Block Comment",
"Entity", "Block Comment".)
6. The non-bold entry now has the color of the bold entry.

I re-ran this test in a few more ways, using the "ada" highlighting mode:

###
Using "Character Constant" (not bold) and "Function" (bold):
###
CC->F->CC->F => F=CC

###
Using "Character Constant" and "Line Comment" (neither bold):
###
Moved between the two freely with no issues.

###
Using all of the non-bold items, in random order:
###
All of the foregrounds remained fine, but the background for "True and False"
got reset to white (from red) in the process. (Ugh! Let's hope that this is part
of the same bug.)

###
Using "Character Constant" and "True and False":
###
CC->TF->CC->TF => TF background is set to white.

###
Using "Character Constant" (With BG color set to blue) and "True and False":
###
Can swap between the two with no problems at all. 

My guess is there's a data structure here that's getting reused without being
cleaned out properly between those reuses. I have 0 experience with GNOME code,
so I can't say much more about what could be going on (and, I'm sorry, that
means I don't have patch either :( ).

I have found the bug; the problem is at
gedit/dialogs/gedit-preferences-dialog.c:1133-1144. The issue is this: the
callback that the toggle buttons are hooked to get called whenever the toggle
button changes state. Normally, this is OK, because the user is the one who
changes thier state. However, when we switch between some entries (like one that
has bold set, and another that doesn't) we toggle those buttons from the code --
leading the update callbacks to be executed, and these nasty side-effects to
take place.

The crappy solution for the time being would be to unregister the callbacks
before we toggle the buttons from inside our program, and then re-register the
callbacks immediately afterward. I don't have a patch yet, but it's late; I may
(!) have one later this week.

Hope this helps...

Created attachment 27538 [details] [review]
A QAD patch to fix the issue with the confused highlighting dialog

Here's the QAD patch to fix the issue with the highlighting dialog. I have not
tested it extensively, but it does appear to be working to solve the bug. The
patch is fairly simplistic, and as such, I do not anticipate any side-effect
bugs to come from it.

Hi Travis, sorry it took so long to look at this... the diagnosis and the
solution seem correct to me. I didn't have time yet to test it though, I'll try
to do it in the next days and - if Paolo (Maggi) agrees - I'll commit both to
the stable and the HEAD branches.

I have some minor nits about the patch (if you can provide a new one great,
otherwise I'll do it myself)
- why not use the simpler g_signal_handler_(un)block_by_func?
- you always pass NULL as the "data" arg, shouldn't it dlg instead?
- to avoid the need for prototypes just shuffle the code
- we prefer
/*
 * blah blah
 */
for multiline comments, beside do not add the bugnumber in the comment. It's
what the ChangeLog is for.
- you missed some whitespaces before the parenthesis to follow the coding style


Thanks again for having investigated this!

Created attachment 29042 [details] [review]
updated patch

Here is the updated patch that I'm going to commit once Paolo acks it (probably
after GUADEC). Works fine.

committed both on HEAD and stable branch