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
next prev parent 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).