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

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

[Gregory Heytings via Emacs development discussions.]

Hi list,

Is the following behavior expected, or is it a bug?

(set-face-attribute 'fringe nil :background "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))

This puts a question mark in the left fringe.  At least on Emacs 26.3 
(started with emacs -Q), after:

(buffer-face-set '(:background "yellow"))

the background of the buffer *and* the question mark in the fringe become 
yellow.  I would have expected that the background of the question mark 
would still be red.

Gregory

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

[Eli Zaretskii]

On July 5, 2020 11:56:00 AM GMT+03:00, "Gregory Heytings via Emacs development discussions." <emacs-devel@gnu.org> wrote:
> 
> Hi list,
> 
> Is the following behavior expected, or is it a bug?
> 
> (set-face-attribute 'fringe nil :background "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))
> 
> This puts a question mark in the left fringe.  At least on Emacs 26.3 
> (started with emacs -Q), after:
> 
> (buffer-face-set '(:background "yellow"))
> 
> the background of the buffer *and* the question mark in the fringe
> become 
> yellow.  I would have expected that the background of the question
> mark 
> would still be red.
> 
> Gregory

You are assuming that 'display' property that draws on the fringe automatically uses the 'fringe' face?  But that's not how this property works: it uses the 'default' face (and thus is subject to face remapping).  To use another face, you need to specify it in the 'left-fringe' form, see the ELisp manual for the details.

IOW, this is not a bug.

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

[Gregory Heytings via Emacs development discussions.]

>
>> Is the following behavior expected, or is it a bug?
>>
>> (set-face-attribute 'fringe nil :background "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))
>>
>> This puts a question mark in the left fringe.  At least on Emacs 26.3 
>> (started with emacs -Q), after:
>>
>> (buffer-face-set '(:background "yellow"))
>>
>> the background of the buffer *and* the question mark in the fringe 
>> become yellow.  I would have expected that the background of the 
>> question mark would still be red.
>>
>> Gregory
>
> You are assuming that 'display' property that draws on the fringe 
> automatically uses the 'fringe' face?  But that's not how this property 
> works: it uses the 'default' face (and thus is subject to face 
> remapping).
>

OK, so one should use:

(put-text-property 0 1 'display '(left-fringe question-mark fringe) s)

>
> To use another face, you need to specify it in the 'left-fringe' form, 
> see the ELisp manual for the details.
>

In fact the manual is not as clear as you think, it states (see https://www.gnu.org/software/emacs/manual/html_node/elisp/Fringe-Bitmaps.html ):

(fringe bitmap [face])

The optional face names a face whose foreground color is used to display 
the bitmap; this face is automatically merged with the fringe face.

For me this means that the fringe face is used to display the bitmaps in 
the fringe, except the :foreground property which can optionally be 
imported from another face.  What actually happens it that the default 
face is used, and that its properties can ben overriden with the 
:foreground and :background properties of another face.  So I do think 
this is a bug, either in the manual or in the code.

Gregory

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

[Eli Zaretskii]

> Date: Sun, 5 Jul 2020 14:43:46 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> OK, so one should use:
> 
> (put-text-property 0 1 'display '(left-fringe question-mark fringe) s)

Yes, if you want to get the 'fringe' face.

> In fact the manual is not as clear as you think, it states (see https://www.gnu.org/software/emacs/manual/html_node/elisp/Fringe-Bitmaps.html ):
> 
> (fringe bitmap [face])
> 
> The optional face names a face whose foreground color is used to display 
> the bitmap; this face is automatically merged with the fringe face.
> 
> For me this means that the fringe face is used to display the bitmaps in 
> the fringe, except the :foreground property which can optionally be 
> imported from another face.

Thanks, I clarified the meaning of FACE in that case.

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

[Gregory Heytings via Emacs development discussions.]

>
>> In fact the manual is not as clear as you think, it states (see https://www.gnu.org/software/emacs/manual/html_node/elisp/Fringe-Bitmaps.html ):
>>
>> (fringe bitmap [face])
>>
>> The optional face names a face whose foreground color is used to 
>> display the bitmap; this face is automatically merged with the fringe 
>> face.
>>
>> For me this means that the fringe face is used to display the bitmaps 
>> in the fringe, except the :foreground property which can optionally be 
>> imported from another face.
>
> Thanks, I clarified the meaning of FACE in that case.
>

Okay, the meaning is clear now.  But, IMO, it would be better to change 
this behavior as follows:

"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.  If @var{face} is omitted, that means 
to use the *@code{fringe}* face."

I at least would expect that the default behavior when displaying 
something in the fringe would be to use the fringe face.  It is then still 
possible to use the 'default' face if one wishes to do so (but why would 
one wish to do this?).  Apparently this change is possible without 
modifying any of the files in the "lisp" directory.

Gregory

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

[Eli Zaretskii]

> Date: Sun, 5 Jul 2020 18:25:33 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> > Thanks, I clarified the meaning of FACE in that case.
> >
> 
> Okay, the meaning is clear now.  But, IMO, it would be better to change 
> this behavior as follows:
> 
> "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.  If @var{face} is omitted, that means 
> to use the *@code{fringe}* face."
> 
> I at least would expect that the default behavior when displaying 
> something in the fringe would be to use the fringe face.

IMO, you are looking at this feature from the wrong angle.  This is a
"replacing" 'display' property that covers some buffer text or overlay
string, and is displayed instead of that buffer text or overlay
string.  Therefore, the natural source of the face information is the
face of the text which is covered by the 'display' property, not the
face of the place where the bitmap is drawn.

In any case, this behavior is very old, so changing it is quite out of
the question.  Especially since having the behavior you consider to be
a better one is so easy.

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

[Gregory Heytings via Emacs development discussions.]

>
>> Okay, the meaning is clear now.  But, IMO, it would be better to change 
>> this behavior as follows:
>>
>> "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.  If @var{face} is omitted, that 
>> means to use the *@code{fringe}* face."
>>
>> I at least would expect that the default behavior when displaying 
>> something in the fringe would be to use the fringe face.
>
> IMO, you are looking at this feature from the wrong angle.  This is a 
> "replacing" 'display' property that covers some buffer text or overlay 
> string, and is displayed instead of that buffer text or overlay string. 
> Therefore, the natural source of the face information is the face of the 
> text which is covered by the 'display' property, not the face of the 
> place where the bitmap is drawn.
>

I don't understand.  The left-fringe and right-fringe display properties 
are there to display something in the fringe, not to change the way the 
text to which they are attached is displayed.  So why would the natural 
source of information be the face of the text?

>
> In any case, this behavior is very old, so changing it is quite out of 
> the question.  Especially since having the behavior you consider to be a 
> better one is so easy.
>

Okay, this makes sense.  Thanks for your attention.

Gregory

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

[Eli Zaretskii]

> Date: Sun, 5 Jul 2020 18:59:23 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> I don't understand.  The left-fringe and right-fringe display properties 
> are there to display something in the fringe, not to change the way the 
> text to which they are attached is displayed.  So why would the natural 
> source of information be the face of the text?

Because that's how these properties work in all other cases, when they
display in the text area.  The fact that this one draws on the fringe
is just a peculiarity.

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

[Gregory Heytings via Emacs development discussions.]

>
>> In fact the manual is not as clear as you think, it states (see https://www.gnu.org/software/emacs/manual/html_node/elisp/Fringe-Bitmaps.html ):
>>
>> (fringe bitmap [face])
>>
>> The optional face names a face whose foreground color is used to 
>> display the bitmap; this face is automatically merged with the fringe 
>> face.
>>
>> For me this means that the fringe face is used to display the bitmaps 
>> in the fringe, except the :foreground property which can optionally be 
>> imported from another face.
>
> Thanks, I clarified the meaning of FACE in that case.
>

Sorry to come back to this, but on a second thought the documentation is 
still not correct:

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.  If @var{face} is omitted, that means 
to use the @code{default} face.

If this were true, then the following two snippets should give the same 
result:

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

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

They do not, the first one displays the question mark in blue on a red 
background, the second one in black on a white background.

To summarize, with:

(set-face-attribute 'fringe nil :background "red" :foreground "blue")
(let ((o (make-overlay 0 1)) (s "_"))
   (put-text-property 0 1 'display '(left-fringe question-mark [1]) s)
   (overlay-put o 'after-string s)) [2]
(buffer-face-set '(:background "yellow" :foreground "red")) [3]

value in [1]: | effect after [2]:   | effect after [3]:
(nothing)     | blue ? on red bg    | red ? on yellow bg
fringe        | blue ? on red bg    | blue ? on red bg
default       | black ? on white bg | red ? on yellow bg

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.

Gregory

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

[Eli Zaretskii]

> Date: Mon, 6 Jul 2020 14:22:16 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> 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).

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

[Gregory Heytings via Emacs development discussions.]

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

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

[Eli Zaretskii]

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

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

[Gregory Heytings via Emacs development discussions.]

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

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

[Gregory Heytings via Emacs development discussions.]

A (last?) note on this.  Fringes were introduced in Emacs 21, and face 
remappings much later, in Emacs 23.  Before face remappings existed (i.e. 
in Emacs 21 and 22), a left/right-fringe display property with an omitted 
face meant using the fringe face without modifications.  It is only when 
face remappings, a feature completely unrelated to fringe displays, were 
introduced, that the current behavior (to use the fringe face when the 
default face has not been remapped, and the remapped default face 
otherwise) started to exist.

Gregory

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

[Eli Zaretskii]

> Date: Tue, 7 Jul 2020 14:59:03 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> A (last?) note on this.  Fringes were introduced in Emacs 21, and face 
> remappings much later, in Emacs 23.  Before face remappings existed (i.e. 
> in Emacs 21 and 22), a left/right-fringe display property with an omitted 
> face meant using the fringe face without modifications.  It is only when 
> face remappings, a feature completely unrelated to fringe displays, were 
> introduced, that the current behavior (to use the fringe face when the 
> default face has not been remapped, and the remapped default face 
> otherwise) started to exist.

This is not what I see.  The left/right-fringe display property (which
was introduced in Emacs 22.1, btw) behaves in Emacs 22 exactly like it
behaves in the current codebase: if the optional FACE parameter is
omitted, it uses the foreground of the 'default' face and the
background of the 'fringe' face (because the 'fringe' face by default
doesn't specify the foreground).  Try this:

  (set-face-attribute 'fringe nil :background "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)
    (set-face-foreground 'default "green"))

and you will see that the foreground of the question-mark bitmap
becomes green.  IOW, Emacs in this case merges the 'fringe' and the
'default' faces, starting from 'default' (so any color specified by
'fringe' overrides the corresponding color of 'default').  By
contrast, when you specify FACE, Emacs merges that face with 'fringe'
starting from 'fringe'.  This different order of merging is what
causes the results which confused you; the implementation didn't
change since it was introduced in Emacs 22.1.

The relation with face remapping is subtle and almost tangential: face
remapping doesn't modify the 'default' face, it creates a new face
which select Emacs features use _instead_ of the original 'default'.

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

[Gregory Heytings via Emacs development discussions.]

>
> This is not what I see.  The left/right-fringe display property (which 
> was introduced in Emacs 22.1, btw) behaves in Emacs 22 exactly like it 
> behaves in the current codebase: if the optional FACE parameter is 
> omitted, it uses the foreground of the 'default' face and the background 
> of the 'fringe' face (because the 'fringe' face by default doesn't 
> specify the foreground).  Try this:
>
>  (set-face-attribute 'fringe nil :background "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)
>    (set-face-foreground 'default "green"))
>

Why did you change my code, which demonstrated the problem, into another 
one which indeed does not show the problem?  Try this:

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

After [1] the behavior is what I expect: red on yellow in the buffer, blue 
on red in the fringe.

After [2] the behavior is *not* what I expect anymore: red on yellow in 
the buffer, red on yellow for the question mark in the fringe (the other 
parts of the fringe remain red, and other bitmaps in the fringe, e.g. 
curly arrows, remain blue on a red background).

Gregory

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

[Eli Zaretskii]

> Date: Tue, 7 Jul 2020 17:47:55 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> >  (set-face-attribute 'fringe nil :background "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)
> >    (set-face-foreground 'default "green"))
> >
> 
> Why did you change my code, which demonstrated the problem, into another 
> one which indeed does not show the problem?

Because I tried to explain something, in the text that you removed.

> Try this:
> 
> (set-face-attribute 'fringe nil :background "red" :foreground "blue")
> (let ((o (make-overlay 0 1)) (s "_"))
>    (put-text-property 0 1 'display '(left-fringe question-mark) s)
>    (overlay-put o 'after-string s))
> (progn (set-face-background 'default "yellow") (set-face-foreground 'default "red")) [1]
> (face-remap-add-relative 'default '(:background "yellow" :foreground "red")) [2]
> 
> After [1] the behavior is what I expect: red on yellow in the buffer, blue 
> on red in the fringe.

Certainly: since in this example the 'fringe' face defines both the
foreground and the background colors, none of the colors of the
'default' face show.

> After [2] the behavior is *not* what I expect anymore: red on yellow in 
> the buffer, red on yellow for the question mark in the fringe (the other 
> parts of the fringe remain red, and other bitmaps in the fringe, e.g. 
> curly arrows, remain blue on a red background).

Because now what you call 'default' is not the original 'default'
face, it's a new face created by face-remapping machinery.

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

[Gregory Heytings via Emacs development discussions.]

>
> Because I tried to explain something, in the text that you removed.
>

I did read it, but it explains the opposite of what happens.

>> Try this:
>>
>> (set-face-attribute 'fringe nil :background "red" :foreground "blue") 
>> (let ((o (make-overlay 0 1)) (s "_"))
>>    (put-text-property 0 1 'display '(left-fringe question-mark) s)
>>    (overlay-put o 'after-string s))
>> (progn (set-face-background 'default "yellow") (set-face-foreground 'default "red")) [1]
>> (face-remap-add-relative 'default '(:background "yellow" :foreground "red")) [2]
>>
>> After [1] the behavior is what I expect: red on yellow in the buffer, 
>> blue on red in the fringe.
>
> Certainly: since in this example the 'fringe' face defines both the 
> foreground and the background colors, none of the colors of the 
> 'default' face show.
>

Indeed.  So far so good.

>
>> After [2] the behavior is *not* what I expect anymore: red on yellow in 
>> the buffer, red on yellow for the question mark in the fringe (the 
>> other parts of the fringe remain red, and other bitmaps in the fringe, 
>> e.g. curly arrows, remain blue on a red background).
>
> Because now what you call 'default' is not the original 'default' face, 
> it's a new face created by face-remapping machinery.
>

Now what you wrote is: "Emacs in this case [with an omitted face] merges 
the 'fringe' and the 'default' faces, starting from 'default' (so any 
color specified by 'fringe' overrides the corresponding color of 
'default')."  So what should happen is that the colors specified by 
'fringe' override the corresponding colors of 'default', which is not the 
case here.  Whether this 'default' one is the original default face or a 
new 'default' face created by face remapping should not matter in this 
case.

Gregory

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

[Eli Zaretskii]

> Date: Tue, 7 Jul 2020 20:47:19 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> Whether this 'default' one is the original default face or a new
> 'default' face created by face remapping should not matter in this
> case.

Well, it does.  because face-remapping creates a new face.

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

[Gregory Heytings via Emacs development discussions.]

>
>> Whether this 'default' one is the original default face or a new 
>> 'default' face created by face remapping should not matter in this 
>> case.
>
> Well, it does.  because face-remapping creates a new face.
>

And?  I really don't get it.  There are two cases:

With an omitted face in a fringe display element, either:

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

or:

(2) When the 'default' face is remapped, Emacs completely ignores the 
'fringe' face, and uses the remapped 'default' face instead.

Gregory

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

[Eli Zaretskii]

> Date: Tue, 7 Jul 2020 21:44:43 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> (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.

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

[Gregory Heytings via Emacs development discussions.]

>
>> (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

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

[Gregory Heytings via Emacs development discussions.]

A small improvement to my suggested documentation:

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}, as an omitted @var{face} leads to 
unexpected behavior.  It is recommended to explicitly indicate the 
@code{fringe} face when one does not want to use specific colors to 
display the bitmap in the fringe.  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.

Gregory

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

[Eli Zaretskii]

> Date: Wed, 8 Jul 2020 09:00:12 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> 
> A small improvement to my suggested documentation:
> 
> 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}, as an omitted @var{face} leads to 
> unexpected behavior.  It is recommended to explicitly indicate the 
> @code{fringe} face when one does not want to use specific colors to 
> display the bitmap in the fringe.  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.

It is not useful to say in the manual that something produces
unexpected results.  So I installed a slightly different description
of this subtlety.

Thanks.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It is not useful to say in the manual that something produces
  > unexpected results.

Yes, it is better to be a little more specific than that.

  >   It is not 
  > > recommended to omit the @var{face}, as an omitted @var{face} leads to 
  > > unexpected behavior.

Why not make that an error instead?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Gregory Heytings via Emacs development discussions.]

>
> > > It is not recommended to omit the @var{face}, as an omitted 
> > > @var{face} leads to unexpected behavior.
>
> Why not make that an error instead?
>

Another possibility, which I didn't think about earlier, would be to 
(implicitly) use an empty face, that is, to make omitting the face 
equivalent to specifying an empty face in 
xdisp.c:handle_single_display_spec().  This works perfectly well:

(defface empty-face '((t nil)) "")
(set-face-attribute 'fringe nil :background "red" :foreground "yellow")
(overlay-put (make-overlay (point) (point)) 'before-string (propertize "_" 'display `(left-fringe question-mark empty-face)))
(text-scale-adjust -1)
(text-scale-adjust +1)

Gregory

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

[Eli Zaretskii]

> Date: Thu, 9 Jul 2020 09:01:16 +0200 (CEST)
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> Another possibility, which I didn't think about earlier, would be to 
> (implicitly) use an empty face, that is, to make omitting the face 
> equivalent to specifying an empty face in 
> xdisp.c:handle_single_display_spec().  This works perfectly well:

There's no reason to change anything in xdisp.c because you can have
what you want without any changes.  It is unwise to change
long-standing behavior because in some situations it could produce
results that might surprise some people.  And now that we have the
documentation more elaborate on this, that confusion should be even
more rare.

It's time we've put this minor issue to rest.

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ghe@sdf.org, emacs-devel@gnu.org
> Date: Wed, 08 Jul 2020 23:01:25 -0400
> 
>   >   It is not 
>   > > recommended to omit the @var{face}, as an omitted @var{face} leads to 
>   > > unexpected behavior.
> 
> Why not make that an error instead?

Because it is not an error, it's an entirely valid usage.

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

[Gregory Heytings via Emacs development discussions.]

>
>> Why not make that an error instead?
>
> Because it is not an error, it's an entirely valid usage.
>

That you do not want to change the code is xdisp.c is one thing, with 
which I'm ok.

That you claim that it's a "entirely valid usage" or a "minor issue" is 
another, and it is plain wrong.  I cannot imagine a single scenario where 
what someone positively wants is to have the colors of an element in the 
fringe change when, for example, the text is scaled up and down.  If you 
have such a case in mind, please provide it.  I filed a bug report against 
diff-mode.el, in which this happens.

What is true is that the default colors of the fringe (black on light 
gray) and the default colors of the buffer (black on white) are close 
enough that many users do not see the difference when this happens.  I 
happen to use a different color for the fringe, and I'd bet I'm not the 
only one to do this.

Note the explanation in NEWS.22, when this display property was 
introduced: "Format is `display (left-fringe BITMAP [FACE])', where BITMAP 
is a symbol identifying a fringe bitmap, either built-in or defined with 
`define-fringe-bitmap', and FACE is an optional face name to be used for 
displaying the bitmap ***instead of the default `fringe' face***. When 
specified, FACE is automatically merged with the `fringe' face."

I took the liberty to add one more message to this already too long 
thread, to answer RMS's question.  Now I stop arguing again.

Thank you for your attention.

Gregory