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

[Gregory Heytings]

> > So it seems that it's only when a face remapping takes place that an 
> > omitted face in [1] means using the default face.  Before the face 
> > remapping takes place, the fringe face is used instead.
>
> 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.

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.

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);

Gregory