Re: buffer-face-set changes the fringe, is it a bug?

[Gregory Heytings]

> Because I tried to explain something, in the text that you removed.

I did read it, but it explains the opposite of what happens.

> > Try this:
> >
> > (set-face-attribute 'fringe nil :background "red" :foreground "blue") 
> > (let ((o (make-overlay 0 1)) (s "_"))
> >    (put-text-property 0 1 'display '(left-fringe question-mark) s)
> >    (overlay-put o 'after-string s))
> > (progn (set-face-background 'default "yellow") (set-face-foreground 'default 
> > "red")) [1]
> > (face-remap-add-relative 'default '(:background "yellow" :foreground "red")) [2]
> >
> > After [1] the behavior is what I expect: red on yellow in the buffer, 
> > blue on red in the fringe.
>
> Certainly: since in this example the 'fringe' face defines both the 
> foreground and the background colors, none of the colors of the 
> 'default' face show.

Indeed.  So far so good.

> > After [2] the behavior is *not* what I expect anymore: red on yellow in 
> > the buffer, red on yellow for the question mark in the fringe (the 
> > other parts of the fringe remain red, and other bitmaps in the fringe, 
> > e.g. curly arrows, remain blue on a red background).
>
> Because now what you call 'default' is not the original 'default' face, 
> it's a new face created by face-remapping machinery.

Now what you wrote is: "Emacs in this case [with an omitted face] merges 
the 'fringe' and the 'default' faces, starting from 'default' (so any 
color specified by 'fringe' overrides the corresponding color of 
'default')."  So what should happen is that the colors specified by 
'fringe' override the corresponding colors of 'default', which is not the 
case here.  Whether this 'default' one is the original default face or a 
new 'default' face created by face remapping should not matter in this 
case.

Gregory