From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juri Linkov'" <juri@jurta.org>
Cc: 1894@emacsbugs.donarmstrong.com
Subject: bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps
Date: Tue, 13 Jan 2009 20:13:33 -0800 [thread overview]
Message-ID: <005301c975fe$77866850$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <87ab9u8ym1.fsf@jurta.org>
> > emacs -Q
> > M-x set-variable special-display-regexps ("[ ]?[*][^*]+[*]")
> >
> > Customize `special-display-frame-alist' to, say, have
> > `background-color' "LightBlue". M-x list-faces-display.
> >
> > The frame displaying buffer *Faces* does not show a LightBlue
> > background. However, the `frame-parameters' for that frame
> > do include (background-color . "LightBlue").
>
> Please see a comment in `list-faces-display':
>
> ;; If the *Faces* buffer appears in a different frame,
> ;; copy all the face definitions from FRAME,
> ;; so that the display will reflect the frame that was selected.
What does it mean? Is this about face definitions? I don't see why. I'm talking
about the frame parameters - the appearance of the frame that is used to show
the individual faces.
Unless that comment is just some kind of a cop-out based on `default' being one
of the faces to portray. How the individual faces, including face `default', are
shown as samples is one thing - I have no problem with that. How the frame
itself is displayed is what I have a problem with.
If you feel you need to tweak things so that the portrayal of face `default'
shows up in the sample list the way that face was defined for the previous
frame, OK (I don't really care about that). But the attributes that face
`default' has in the *Faces* frame should not override and interfere with the
normal display of a buffer named `*Faces*'.
And why would such an exceptional behavior - not respecting
`special-display-regexps' - be explained only in a comment? How would a user of
`list-faces-display' know about this odd behavior?
IIRC, this change dates from when we started to treat face `default' as
synonymous with the corresponding frame parameters (`background-color' etc.).
IOW, it is more an _implementation side effect_ than a "feature". There is no
reason, from a _users's_ point of view, to confuse the _portrayal_ of a face
with the _use_ of that face to display a frame of face samples.
Is this confusion of use and mention just a result of implementation laziness?
Think about the UI from the user's point of view - and that includes the user's
control of frame appearance using `special-display-regexps' (and
`default-frame-alist' and ...).
The _effect_, for the user, was coherent and clear in Emacs 20 (probably 21 also
- haven't checked). Now the entire display changes, depending on whichever frame
you call the command from. That's not helpful or needed - it's enough to show
the `default' face's sample, like each of the other faces. In this case, it's
not right to simply use that face to define the frame properties for the *Faces*
frame.
A proper fix would show the `default' face using its definition from the
originating frame (if you consider that feature worthwhile - I don't care), and
_label it as such_: "default (in frame blah-blah)", where only the name
`default' is a link (underlined) to the face details. That information is
completely missing for the user currently.
But leave the frame's "face" parameters alone - treat it just as any other
similar frame would be treated: if the `special-display-*' stuff applies, use
that; otherwise use `default-frame-alist' or whatever else would normally take
effect.
This is poor UI, and it sounds like it might also represent lazy programming.
My other comments should also be addressed:
* About the appropriate frame "face" parameters appearing in certain
circumstances (leaking in) - display portion after the buffer text, right side
of minibuffer, showing full-frame ephemerally when you resize. Very ugly -
obviously a bugged appearance.
* About this "feature" being a mystery to users - explained only in a code
comment.
Put on your thinking caps as users, not just as implementors. There is a better
way.
prev parent reply other threads:[~2009-01-14 4:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 19:41 bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps Drew Adams
2009-01-14 1:18 ` Juri Linkov
2009-01-14 1:47 ` Glenn Morris
2009-01-14 4:29 ` Drew Adams
2009-01-14 4:13 ` Drew Adams [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='005301c975fe$77866850$0200a8c0@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=1894@emacsbugs.donarmstrong.com \
--cc=juri@jurta.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.