[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gregory Heytings
Subject: Re: buffer-face-set changes the fringe, is it a bug?
Date: Mon, 6 Jul 2020 19:08:39 +0200 (CEST)
User-agent: Alpine 2.21 (NEB 202 2017-01-01)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]