unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: buffer-face-set changes the fringe, is it a bug?
Date: Wed, 8 Jul 2020 08:55:15 +0200 (CEST)	[thread overview]
Message-ID: <alpine.NEB.2.21.2007080825350394.3867@sdf.lonestar.org> (raw)
In-Reply-To: <83wo3erbga.fsf@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.
>

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



  reply	other threads:[~2020-07-08  6:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-05  8:56 buffer-face-set changes the fringe, is it a bug? Gregory Heytings via Emacs development discussions.
2020-07-05 10:50 ` Eli Zaretskii
2020-07-05 12:43   ` Gregory Heytings via Emacs development discussions.
2020-07-05 15:32     ` Eli Zaretskii
2020-07-05 16:25       ` Gregory Heytings via Emacs development discussions.
2020-07-05 16:40         ` Eli Zaretskii
2020-07-05 16:59           ` Gregory Heytings via Emacs development discussions.
2020-07-05 17:24             ` Eli Zaretskii
2020-07-06 12:22       ` Gregory Heytings via Emacs development discussions.
2020-07-06 16:41         ` Eli Zaretskii
2020-07-06 17:08           ` Gregory Heytings via Emacs development discussions.
2020-07-06 18:08             ` Eli Zaretskii
2020-07-06 18:55               ` Gregory Heytings via Emacs development discussions.
2020-07-07 12:59                 ` Gregory Heytings via Emacs development discussions.
2020-07-07 14:59                   ` Eli Zaretskii
2020-07-07 15:47                     ` Gregory Heytings via Emacs development discussions.
2020-07-07 18:34                       ` Eli Zaretskii
2020-07-07 18:47                         ` Gregory Heytings via Emacs development discussions.
2020-07-07 19:20                           ` Eli Zaretskii
2020-07-07 19:44                             ` Gregory Heytings via Emacs development discussions.
2020-07-08  2:24                               ` Eli Zaretskii
2020-07-08  6:55                                 ` Gregory Heytings via Emacs development discussions. [this message]
2020-07-08  7:00                                   ` Gregory Heytings via Emacs development discussions.
2020-07-08 14:41                                     ` Eli Zaretskii
2020-07-09  3:01                                       ` Richard Stallman
2020-07-09  7:01                                         ` Gregory Heytings via Emacs development discussions.
2020-07-09 17:17                                           ` Eli Zaretskii
2020-07-09 17:14                                         ` Eli Zaretskii
2020-07-10 10:24                                           ` Gregory Heytings via Emacs development discussions.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.NEB.2.21.2007080825350394.3867@sdf.lonestar.org \
    --to=emacs-devel@gnu.org \
    --cc=ghe@sdf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).