Slight bug in the `gnus-use-correct-string-widths' implementation.

[Daniel Pittman <daniel@rimspace.net>]

The implementation of `gnus-use-correct-string-widths' is really nifty
and stuff, but it's not /quite/ complete at the moment.

When I go into a summary buffer with the following format:

(setq gnus-summary-line-format "%U%R%[%(%4,-4uL %ub%-20,20f%)%]: %B%S\n")

This expands, in the evaluation of the code, to the following Lisp:

,----
| (let ((val (eval (gnus-summary-from-or-to-or-newsgroups gnus-tmp-header))))
|   (if (> (gnus-correct-length val) 20)
|     (gnus-correct-substring val 0 20) val))
`----

As far as I can see, this is the /only/ time that Gnus tries to limit
the length for the `%-20,20f' expansion in the code above.

Now, that isn't strictly correct because, deep inside the code
somewhere, the result of that function (6 columns) is padded with spaces
-- 17 of them.

I get the following header:

! [ 668  Brian J. Watson     ]: [PATCH 2.4.7] generic hash table implementation
! [ 251  Jason Thomas        ]: [PATCH] patch's for vmware 2.0.4 for use with linux-2.4.8 kernel
  [ 810  김용일                 ]: presario 1700 lan card
  [  20 +David S. Miller     ]: Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

So, it looks like something in the padding code for summary lines isn't
quite right, at least on XEmacs, for `gnus-use-correct-string-widths'.

      Daniel

-- 
It's a kind of war
Where I plant bombs inside
of myself
        -- Anne Sexton, _The Addict_