GNU bug report logs - #1894
23.0.60; list-faces-display does not respect special-display-regexps

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>
Cc: <1894 <at> debbugs.gnu.org>
Subject: bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps
Date: Tue, 13 Jan 2009 20:13:33 -0800

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.