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

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

[Drew Adams]

Filed this bug in 2007, so it probably wasn't added to the new bug
database. Below is the original report. 
 
This is an update to say that the problem remains in the pretest
(Emacs 22.2.91). 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'.
 
Dunno why. Other special-display buffers, such as *Pp Eval Output*,
use the correct frame parameters (from `special-display-frame-alist').

Another, perhaps related problem: When I hit C-c C-c in the bug-reporting
buffer, that buffer was replaced in the same frame with buffer *Pp Eval Output*,
so this buffer has the frame parameters of `default-frame-alist'. This is not
right: *Pp Eval Output* should always be in its own, dedicated frame with the
`special-display-frame-alist' frame parameters (given my setup, described
below). 

IOW, if *Pp Eval Output* is shown via `pp-eval-expression' it is shown
correctly, but C-c C-c in the bug report buffer placed *Pp Eval Output* in the
same frame, not respecting `special-display-regexps' and
`special-display-frame-alist'.
 
Here's the original bug report:
 
------------8<---------------------------
 
> From: Drew Adams
> Sent: Thursday, November 22, 2007 8:38 AM
> To: Bug-Gnu-Emacs
> Subject: RE: list-faces-display imposes its own 
> background,doesn't respect special-display-frame-alist
> 
> Resending, consolidating the three separate mails, in case 
> this got lost.
> 
> > From: Drew Adams Sent: Tuesday, October 23, 2007 3:33 PM
> >
> > emacs -Q
> >
> > Evaluate these sexps:
> >
> > (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
> >
> > (setq special-display-frame-alist
> >       '((foreground-color . "Black")
> >         (background-color . "LightSteelBlue")))
> >
> > (setq pop-up-frames t)
> >
> > (defun special-display-popup-frame (buffer &optional args)
> >   "Display BUFFER in its own frame, reusing an existing 
> window if any.
> > Return the window chosen.  Window is not selected within its frame.
> >
> > If a new frame is needed, then `make-frame' is called to create it,
> > with BUFFER as the current buffer.
> >
> > If ARGS is an alist, use it as a list of frame parameter specs.
> > If ARGS is a list whose car is a symbol, use (car ARGS) as 
> a function
> > to do the work.  Pass it BUFFER as first arg, and (cdr ARGS) as the
> > rest of its args."
> >   (if (and args (symbolp (car args)))
> >       (let* ((window (apply (car args) buffer (cdr args)))
> >              (frame (window-frame window)))
> >         (when (fboundp 'fit-frame) (fit-frame (window-frame 
> window)))
> >         (raise-frame frame)
> >         window)                         ; Return the window.
> >     (let ((window (get-buffer-window buffer 0)))
> >       (or
> >        ;; If we have a window already, make it visible.
> >        (when window
> >          (let ((frame (window-frame window)))
> >            (make-frame-visible frame)
> >            (raise-frame frame)
> >            (when (fboundp 'fit-frame) (fit-frame frame))
> >            window))                     ; Return the window.
> >        ;; Reuse the current window if the user requested it.
> >        (when (cdr (assq 'same-window args))
> >          (condition-case nil
> >              (progn (switch-to-buffer buffer) (selected-window))
> >            (error nil)))
> >        ;; Stay on the same frame if requested.
> >        (when (or (cdr (assq 'same-frame args)) (cdr (assq 
> 'same-window
> > args)))
> >          (let* ((pop-up-frames nil) (pop-up-windows t)
> >                 special-display-regexps special-display-buffer-names
> >                 (window (display-buffer buffer)))
> >            ;; Only do it if this is a new window:
> >            ;; (set-window-dedicated-p window t)
> >            window))                     ; Return the window.
> >
> >        ;; If no window yet, make one in a new frame.
> >        (let ((frame (with-current-buffer buffer
> >                       (make-frame (append args
> > special-display-frame-alist)))))
> >          (when (and (fboundp 'fit-frame)
> >                     (not (memq 'fit-frame 
> after-make-frame-functions)))
> >            (with-current-buffer buffer (fit-frame frame)))
> >          (set-window-buffer (frame-selected-window frame) buffer)
> >          (set-window-dedicated-p (frame-selected-window frame) t)
> >          (frame-selected-window frame)))))) ; Return the window.
> >
> > Try C-h f setq - no problem. The frame background is LightSteelBlue.
> >
> > Try M-x list-faces-display. The frame background, or at least the
> > background of buffer *Faces*, is white. The frame background appears
> > to be LightSteelBlue, which is correct, but that only shows in the
> > fringe and the minibuffer. (So, for a frame without minibuffer and
> > fringe, no LightSteelBlue background is seen.
> >
> > `list-faces-display' should not impose a special background for its
> > window/buffer. (And how does it do that, anyway?)
> >
> > I should add that list-colors-display does not have this problem.
> > list-faces-display should act the same way.
> >
> > Also, in case it helps, the background is not imposed as white.
> > It appears that the default frame background is what is imposed
> > for the *Faces* buffer.
> >
> >
> > In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
> >  of 2007-06-02 on RELEASE
> > Windowing system distributor `Microsoft Corp.', version 5.1.2600
> > configured using `configure --with-gcc (3.4) --cflags
> > -Ic:/gnuwin32/include'
> >
> > Important settings:
> >   value of $LC_ALL: nil
> >   value of $LC_COLLATE: nil
> >   value of $LC_CTYPE: nil
> >   value of $LC_MESSAGES: nil
> >   value of $LC_MONETARY: nil
> >   value of $LC_NUMERIC: nil
> >   value of $LC_TIME: nil
> >   value of $LANG: ENU
> >   locale-coding-system: cp1252
> >   default-enable-multibyte-characters: t
> >
> > Major mode: Emacs-Lisp
> >
> > Minor modes in effect:
> >   encoded-kbd-mode: t
> >   tooltip-mode: t
> >   tool-bar-mode: t
> >   mouse-wheel-mode: t
> >   menu-bar-mode: t
> >   file-name-shadow-mode: t
> >   global-font-lock-mode: t
> >   font-lock-mode: t
> >   blink-cursor-mode: t
> >   unify-8859-on-encoding-mode: t
> >   utf-translate-cjk-mode: t
> >   auto-compression-mode: t
> >   line-number-mode: t
> >
> > Recent input:
> > <help-echo> C-x C-f o o o . e l <return> <help-echo>
> > <help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
> > <help-echo> M-x l o a d - f <return> <return> C-h f
> > <return> <switch-frame> C-x k <return> M-x l i s d
> > t - <backspace> <backspace> <backspace> t - f a c e
> > <return> <switch-frame> C-x k C-g <help-echo> <help-echo>
> > <switch-frame> <help-echo> <help-echo> <help-echo>
> > <help-echo> <help-echo> <help-echo> <menu-bar> <help-menu>
> > <report-emacs-bug>
> >
> > Recent messages:
> > ("C:\\Emacs-22.1\\bin\\emacs.exe" "-Q" "--debug-init" 
> "C:\\drews-lisp-20")
> > Loading encoded-kb...done
> > For information about the GNU Project and its goals, type C-h C-p.
> > Loading dired...
> > Loading regexp-opt...done
> > Loading dired...done
> > Loading c:/drews-lisp-20/ooo.el (source)...done
> > Loading help-fns...done
> > Quit
> > Loading emacsbug...done
 
 
 
In GNU Emacs 22.2.91.1 (i386-mingw-nt5.1.2600)
 of 2008-08-27 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t
 
Major mode: Help
 
Minor modes in effect:
  display-time-mode: t
  savehist-mode: t
  icomplete-mode: t
  tool-bar-pop-up-mode: t
  icicle-mode: t
  minibuffer-depth-indicate-mode: t
  pretty-control-l-mode: t
  delete-selection-mode: t
  tabbar-mode: t
  show-paren-mode: t
  encoded-kbd-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t
 

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

[Glenn Morris]

tags 797 notabug wontfix
stop

"Drew Adams" wrote:

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

Processed: Re: list-faces-display imposes its own background, doesn't respect special-display-frame-alist

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> tags 797 notabug wontfix
bug#797: list-faces-display imposes its own background,doesn't respect special-display-frame-alist
There were no tags set.
Tags added: notabug, wontfix

> stop
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

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

[Drew Adams]

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

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

[Drew Adams]

The bug should not be closed with no comment.
It should either be fixed or declared not a bug.

But it is a bug.  And a regression at that.