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

[Gregory Heytings]

> > (2) When the 'default' face is remapped, Emacs completely ignores the 
> > 'fringe' face, and uses the remapped 'default' face instead.
>
> It doesn't "ignore", but because the remapped face specifies both 
> colors, the fringe colors don't show.  That's what happens when you 
> merge two faces one of which specifies both colors: if the face that 
> specifies both colors is merged last, the colors of the first one will 
> not show.

And the question is precisely: why is the default face merged LAST in this 
case when, according to the documentation and to what you wrote, it should 
be merged FIRST?

IOW, there are two cases:

(1) "Emacs merges the 'fringe' and the 'default' faces, starting from 
'default' (so any color specified by 'fringe' overrides the corresponding 
color of 'default')."

(2) When the 'default' face is remapped, Emacs merges the 'fringe' and the 
'default' faces, starting from 'fringe' (which effictively means that, 
given that 'default' always specifies a foreground and a background, any 
color specified by 'fringe' will be overridden).

Four more examples:

(a) This works even if the remapping of the default face does not change 
the color specified for the fringe face.  Try this:

(set-face-attribute 'fringe nil :foreground "red")
(let ((o (make-overlay 0 1)) (s "_"))
  (put-text-property 0 1 'display '(left-fringe question-mark) s)
  (overlay-put o 'after-string s))
(face-remap-add-relative 'default '(:background "yellow"))

(b) This works even if the remapping of the default face does not change 
the colors at all.  Try this:

(set-face-attribute 'fringe nil :background "red" :foreground "yellow")
(let ((o (make-overlay 0 1)) (s "_"))
  (put-text-property 0 1 'display '(left-fringe question-mark) s)
  (overlay-put o 'after-string s))
(face-remap-add-relative 'default '(:weight bold))

(c) This works even if the remapping of the default face does not change 
anything visually.  Try this:

(set-face-attribute 'fringe nil :background "red" :foreground "yellow")
(let ((o (make-overlay 0 1)) (s "_"))
  (put-text-property 0 1 'display '(left-fringe question-mark) s)
  (overlay-put o 'after-string s))
(face-remap-add-relative 'default `(:weight ,(face-attribute 'default :weight)))

(d) This works also when one simply adjust the text scale with C-x C-- and 
C-x C-+:

(set-face-attribute 'fringe nil :background "red" :foreground "yellow")
(let ((o (make-overlay 0 1)) (s "_"))
  (put-text-property 0 1 'display '(left-fringe question-mark) s)
  (overlay-put o 'after-string s))
(text-scale-adjust -1)
(text-scale-adjust +1)

After C-x C-- the question mark is black on white, after C-x C-+ the 
question mark is yellow on red again.

I start arguing now.  Apparently this behavior is old enough that it is 
now, by definition, a feature.  Moreover I'm the only one who took part of 
this thread, so it is perhaps not important.  But please adjust the 
documentation (I've just seen that you updated it twice already) as 
follows:

The optional @var{face} names a face whose foreground and background 
colors are to be used to display the bitmap, using the attributes of the 
@code{fringe} face for colors that @var{face} didn't specify.  It is not 
recommended to omit the @var{face}, and to explicitly indicate the 
@code{fringe} face when one does not want to use specific colors to 
display the bitmap in the fringe, as an omitted @var{face} leads to 
unexpected behavior.  If @var{face} is omitted and the @code{default} face 
is not remapped, that means to use the attributes of the @code{default} 
face for the colors which the @code{fringe} face didn't specify.  If 
@var{face} is omitted and the @code{default} face is remapped, that means 
to use the attributes of the @code{fringe} face for the colors which the 
@code{default} face didn't specify.

Thank you (once again) for your attention.

Gregory