emacs-devel
[Top][All Lists]
Advanced

[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 20:55:04 +0200 (CEST)
User-agent: Alpine 2.21 (NEB 202 2017-01-01)



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.


... and to make sense of what the documentation says. I think this is problematic.


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.


So the documentation should be:

The optional @var{face} names a face whose foreground and background colors are to be used to display the bitmap; this face is automatically merged with the @code{fringe} face. When @var{face} is omitted and the @code{default} face has not been remapped, that effectively means to use the @code{fringe} face. When @var{face} is omitted and the @code{default} face has been remapped, that means to use the remapped @code{default} face. It is not recommended to omit the @var{face}: it is recommended to indicate the @code{fringe} face when one does not want to use another face.

Compare this with what one would naturally expect, and which is in fact very close to the previous version of the documentation:

The optional @var{face} names a face whose foreground and background colors are to be used to display the bitmap; this face is automatically merged with the @code{fringe} face. When @var{face} is omitted, this means to use the @code{fringe} face.


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_basic_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.


Hmmm... I don't think they are convincing, and I do think that the current behavior is not what one would naturally expect. But I'm not in a position to impose anything.

Thanks again for your attention.

Gregory



reply via email to

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