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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 6 Jul 2020 19:08:39 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> > No, it uses the default face, but the result is produced slightly 
> > differently (not by actually merging the two faces).
> >
> 
> Sorry, but that doesn't make any sense.  The default face does not contain 
> any blue or red, it's black on white.  So how could blue or red enter into 
> the face when no face is specified (i.e. when the face is omitted)?  At 
> the very least, this is not what one understands with the (previous or 
> current) documentation.

You need to look at the code to make sense of what I said.

> I'm not entirely sure, but apparently the logic in draw_fringe_bitmap_1() 
> is to take DEFAULT_FACE_ID as an initial value for face_id, and if face_id 
> is not set explicitly to a different value, to reset its value to 
> FRINGE_FACE_ID.
> 
> In handle_single_display_spec(), face_id is initially set to 
> DEFAULT_FACE_ID, which means (given the above) that when face is omitted 
> it is FRINGE_FACE_ID that will in fact be used.  When face is 'fringe' the 
> derived face that is created is equivalent to FRINGE_FACE_ID.  When face 
> is explicitly set to 'default', a derived face is created, and is 
> subjected to face remappings in the buffer.

Yes.

> I think again that this is a bug, and that one should have (if my 
> understanding is correct), in handle_single_display_spec():
> 
> int face_id = lookup_fasic_Face (it->f, FRINGE_FACE_ID);
> 
> instead of:
> 
> int face_id = lookup_basic_face (it->f, DEFAULT_FACE_ID);

I disagreed already, and provide my reasons.