bug#797: list-faces-display imposes its own background, doesn't respect special-display-frame-alist

["Drew Adams" <drew.adams@oracle.com>]

> tags 797 notabug wontfix
> 
> > Filed this bug in 2007, so it probably wasn't added to the new bug
> > database. Below is the original report. 
> 
> Thanks for taking the time to tidy up and trim your report!
> 
> > Now, the symptom is that the parameters (e.g. background) of
> > `default-frame-alist' are used for buffer *Faces*, instead of the
> > parameters of `special-display-frame-alist'.
> 
> By design, M-x list-faces-display shows faces as they appear in the
> frame from which it was called. Try calling it from a special frame,
> or scrolling to the end of the sample faces.

Hi Glenn,

That is a bad design, IMO, if design it is. It contradicts the user's settings
for special-display buffers. There is no excuse for that. If the user wants the
`list-faces-display' output (buffer *Faces*) to be in a Hello Kitty frame color
scheme, then that wish should be respected. Where does the `list-faces-display'
programmer get off redesigning this to conflict with this Emacs rule?

BTW, scrolling to the end of *Faces*, as you suggest, shows that the user's
preferred frame background is in fact respected, but all of the text (including
the whitespace) displayed in the buffer overrides this frame background color,
so the frame background is smothered. That explains the mechanism, but it
doesn't justify the effect: the user's preference is overridden, and it should
not be.

What is the rationale for this? There is nothing that says that the previous
frame - the frame from which `list-faces-display' was called (interactively or
by program) has the background that the user wants for *Faces*. Nothing
whatsoever - no logical connection. This is a bad "feature" - it's what I would
call an intentional bug.