With a lot of help from Jesper Harder, I have identified a problem in
Oort Gnus running under XEmacs.

The problem arises when a user format function returns a string with
text properties set. My original example was a
"gnus-user-format-function-f" which returned the sender's name
(basically like %f) but the name is in red if the sender is in my
BBDB.

I set the properties '(gnus-face t face red), but found that the
summary buffer did not show the colour. On investigation, it became
clear that the problem was that gnus-parse-simple-format produces a
form which uses FORMAT to generate the summary line. On FSF Emacs,
format preserves text properties, but in XEmacs, it does not,
returning a string with no properties set.

The attached patch fixes this problem. It's a little rough around the
edges, mainly because I have pretty much no experience in elisp
programming, but it does fix the problem for me.

Is it possible for this workaround to be included, in some form, in
Gnus proper? I don't see any way of fixing the problem in user code
(ie, *without* patching Gnus).

Some things which need to be addressed (and which are basically beyond
me...)

1. The code I added to gnus-parse-simple-format only uses
   gnus-simple-format for XEmacs. This is to avoid FSF Emacs users
   having to take a performance hit from using a Lisp function where
   their built-in format function is fine. Jesper suggested using
     (eval-and-compile
        (unless (featurep 'xemacs)
           (defalias 'gnus-simple-format 'format)))
   instead, but (a) I couldn't decide where to put it, and (b) I
   suspect my solution is simpler. But I'm not sure, and I have no FSF
   Emacs to test it on, so I'd appreciate comments.

2. The code only handles %s and %%. Under XEmacs these are the only
   two format codes which are generated. However, if
   gnus-use-correct-string-widths is false in XEmacs, %Ns codes are
   generated (for numeric N). Adding code to gnus-simple-format to
   cope with this case is possible, but it complicates (and slows
   down) the code. Is it worth it? Alternatively, is there another way
   of achieving the same effect - maybe make Gnus never generate the
   %Ns codes for XEmacs (the gnus-use-correct-string-widths code
   %manages it by trimming the strings before passing them to format,
   %I think - is something similar possible?)

3. The whole thing (using a format replacement coded in lisp) is going
   to give a performance hit. I'm sure my code isn't anywhere near
   optimal - can anyone help in making it faster?

4. Even if optimised, the whole thing is still going to be slower than
   using format directly. And as it only causes problems in a few
   obscure cases, would it be worth making the whole thing optional,
   via a user configuration option? I've not the slightest idea how to
   do something like that, so I'm afraid I can't offer code here, just
   the suggestion (and the suggestion was originally Jesper's in any
   case :-))

I'd appreciate any comments - this is my first attempt at submitting a
patch for Gnus, so I apologise if I've made any obvious blunders, in
coding or in procedure.

Thanks in particular to Jesper, who helped me follow this through
until I understood precisely where the problem lay.

Paul.