Setting the background color of the minibuffer

Setting the background color of the minibuffer

[Óscar Fuentes]

Is it possible to set the background color (the face, in general terms)
of the minibuffer (and only of the minibuffer) without using a dedicated
frame for it?

What I'm attempting is to set a black background for the minibuffer
while working in full-screen mode. This way the minibuffer looks like
part of the monitor's perimeter and not as an empty line at the bottom
of the screen.

Re: Setting the background color of the minibuffer

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 10 Dec 2014 05:07:44 +0100
> 
> Is it possible to set the background color (the face, in general terms)
> of the minibuffer (and only of the minibuffer) without using a dedicated
> frame for it?

Did you try face-remapping?

Re: Setting the background color of the minibuffer

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Is it possible to set the background color (the face, in general terms)
>> of the minibuffer (and only of the minibuffer) without using a dedicated
>> frame for it?
>
> Did you try face-remapping?

Yes. Something like this:

Starting from

http://stackoverflow.com/questions/12654592/change-the-background-color-of-the-minibuffer-when-input-is-needed

where the solution is:

(add-hook 'minibuffer-setup-hook
          (lambda ()
            (make-local-variable 'face-remapping-alist)
            (add-to-list 'face-remapping-alist
                         '(default (:background "green")))))


That works as advertised: the background changes when you are working on
the minibuffer.

However, I want the background changed permanently. So I tried:

(dolist (b (buffer-list))
  (when (minibufferp b)
    (with-current-buffer b
      (make-local-variable 'face-remapping-alist)))
      (add-to-list 'face-remapping-alist
		   '(default (:background "black"))))

but that changes the background of all buffers. And the minibuffer, when
it is empty, eventually comes back to the original background.

Re: Setting the background color of the minibuffer

[Stefan Monnier]

> That works as advertised: the background changes when you are working on
> the minibuffer.
> However, I want the background changed permanently. So I tried:

That's because when the minibuffer is not active, the mini window does
not display any "minibuffer" but it displays the "echo area buffer"
instead (of which there are two).

So you'll probably want to set face-remapping-alist in " *Echo Area 0*"
and " *Echo Area 1*".


        Stefan

Re: Setting the background color of the minibuffer

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 10 Dec 2014 17:24:22 +0100
> 
> > Did you try face-remapping?
> 
> Yes. Something like this:
> 
> Starting from
> 
> http://stackoverflow.com/questions/12654592/change-the-background-color-of-the-minibuffer-when-input-is-needed
> 
> where the solution is:
> 
> (add-hook 'minibuffer-setup-hook
>           (lambda ()
>             (make-local-variable 'face-remapping-alist)
>             (add-to-list 'face-remapping-alist
>                          '(default (:background "green")))))
> 
> 
> That works as advertised: the background changes when you are working on
> the minibuffer.
> 
> However, I want the background changed permanently.

Doesn't it work to do that in just the minibuffer buffers, specified
by their names?

Re: Setting the background color of the minibuffer

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That works as advertised: the background changes when you are working on
>> the minibuffer.
>> However, I want the background changed permanently. So I tried:
>
> That's because when the minibuffer is not active, the mini window does
> not display any "minibuffer" but it displays the "echo area buffer"
> instead (of which there are two).
>
> So you'll probably want to set face-remapping-alist in " *Echo Area 0*"
> and " *Echo Area 1*".

(dolist (b (buffer-list))
  (when (or (string= (buffer-name b) " *Echo Area 0*")
	    (string= (buffer-name b) " *Echo Area 1*"))
    (with-current-buffer b
      (make-local-variable 'face-remapping-alist)))
      (add-to-list 'face-remapping-alist
		   '(default (:background "black"))))

Same result: changes the background of all buffers and the mini window
reverts to the previous background from time to time (often when there
is no content to show on the mini window.)

GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, X toolkit) of 2014-11-18

Re: Setting the background color of the minibuffer

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Doesn't it work to do that in just the minibuffer buffers, specified
> by their names?

No, same result.

One thing I observed it that the behaviour differs depending whether I
use my config or `emacs -Q'. With the former, results are predictable.
With `emacs -Q', at first it looks like it works, but after a few
operations (switching buffers, for instance) the background is applied
to the other buffers. Looks like a bug.

Re: Setting the background color of the minibuffer

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 10 Dec 2014 18:17:58 +0100
> 
> One thing I observed it that the behaviour differs depending whether I
> use my config or `emacs -Q'. With the former, results are predictable.
> With `emacs -Q', at first it looks like it works, but after a few
> operations (switching buffers, for instance) the background is applied
> to the other buffers. Looks like a bug.

If you can come up with  reproducible recipe, please file a bug
report.

Re: Setting the background color of the minibuffer

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> One thing I observed it that the behaviour differs depending whether I
>> use my config or `emacs -Q'. With the former, results are predictable.
>> With `emacs -Q', at first it looks like it works, but after a few
>> operations (switching buffers, for instance) the background is applied
>> to the other buffers. Looks like a bug.
>
> If you can come up with  reproducible recipe, please file a bug
> report.

Done as bug#19339.