bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps

bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps

[Drew Adams]

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").
 
And the right part of the minibuffer shows a LightBlue background. And
if you scroll down past the end of the buffer, a LightBlue background
appears.  And while you resize the frame the whole frame
intermittently shows a LightBlue background, but as soon as you are
finished resizing it the background goes back to being the default
(White).
 
This is ugly and uncalled for. Display of the frame should respect the
frame parameters that are defined for it. The faces themselves are
shown in their own colors; that is sufficient. There is no need to
also alter the background shown for all of the buffer text, overriding
the frame parameters.
 
This bug exists also for Emacs 22.

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2009-01-04 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 

bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps

[Juri Linkov]

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

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps

[Glenn Morris]

Juri Linkov wrote:

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

(As explained the first time round, in bug#797.)

bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps

[Drew Adams]

> > 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.
> 
> (As explained the first time round, in bug#797.)

Too bad you didn't get it right the first time round.
This is regress, not progress, from a user point of view.

bug#1894: 23.0.60; list-faces-display does not respect special-display-regexps

[Drew Adams]

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