On 27 Jan 2009, at 14:16, Chong Yidong wrote:
>
> I don't see any bug here.  The "test" string inserted into the buffer
> has a background different from `highlight', but that's because its
> background is not unspecified:

You are right, mea culpa.  My test case wasn't correct.

To reproduce, we also need overlays with before/after-string properties.

To demonstrate:

(require 'csv-mode)
(csv-mode)
(set (make-local-variable 'face-remapping-alist) '((default .  
highlight)))

Enter something like this:

8,1,4,5
9912919,112312,543453,444

Mark all, then C-c C-a  (csv-align-fields)

The result, for me at least, is shown in the first screenshot.

CSV-Mode uses overlays for the separators.  From my brief analysis of  
the code (`csv-align-fields'), it seems to use overlays with `before- 
string' and `after-string' properties to mark spaces to the left and  
to the right of each field. (In the code, right after "Display spaces  
before field:" and ";; Display spaces after field:")
This `before-string' is not rendered using the correct face, i.e. it  
does not respect face-remapping-alist. This can be seen in the  
screenshots.

I suspect that the `before-string' overlays are rendered using the  
adjacent face for the comma, which is, per font-locking, set to `csv- 
separator-face'.  And that is where the inheritance issue plays a  
role.  If you M-x customize-face csv-separator-face, and set the  
`inherit' attribute to default, then you should see things change  
(screenshot 1 to 2).  Setting the inheritance to `default'  should  
never result in any visible change.

I'm sure I could provide a minimal example if I had more time, but I  
hope that the analysis was enough to let you reproduce this issue with  
`before-string' and `after-string'.

PS: The practical problem for the user was not a matter of background  
colors, but to choose a fixed-width font for `csv-mode' buffers when  
the `default' face is variable-width, in order to get the numbers to  
align properly.