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

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Wed, 27 Aug 2008 17:05:05 UTC

Severity: normal

Tags: notabug, wontfix

Merged with 1894

Done: Lars Magne Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Glenn Morris'" <rgm <at> gnu.org>, <797 <at> debbugs.gnu.org>
Subject: bug#797: list-faces-display imposes its own background,doesn't respect special-display-frame-alist
Date: Thu, 25 Sep 2008 09:09:00 -0700
> 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.





This bug report was last modified 13 years and 317 days ago.

Previous Next


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