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: Eli Zaretskii
Subject: Re: buffer-face-set changes the fringe, is it a bug?
Date: Tue, 07 Jul 2020 17:59:34 +0300

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



reply via email to

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