Window background color

Window background color

[David Reitter]

How does one set the background color of a window?

I use `face-remapping-alist' to define a `default' face for a buffer,  
with a specific background color.  This works fine unless the buffer  
is small and does not fill the whole window, or if I scroll to the  
end.  The area between the last line of the buffer and the bottom of  
the window is drawn in the frame's background color, rather than in  
the background color assigned with the default face in that buffer.

(I see this in a 23 CVS (Cocoa port) build.)

It appears that only a frame parameter is used and that the frame is  
cleared using a rif->clear_frame_area call, which is not specific to  
windows.  I haven't found the right fix for this so far.  Would it be  
sensible to change clear_frame_area to establish the right background  
color, i.e. the one associated with the default face appropriate for  
the buffer shown in the window (updated_window), and only default to  
the frame's background?

Re: Window background color

[Miles Bader]

David Reitter <david.reitter@gmail.com> writes:
> It appears that only a frame parameter is used and that the frame is
> cleared using a rif->clear_frame_area call, which is not specific to
> windows.  I haven't found the right fix for this so far.  Would it be
> sensible to change clear_frame_area to establish the right background
> color, i.e. the one associated with the default face appropriate for
> the buffer shown in the window (updated_window), and only default to
> the frame's background?

In my "tiling" branch, I've fixed some of that by adding a "clear window area"
operation that can do window-specific handling, and changing appropriate
callers to use that.

Maybe I should merge some of the more generic changes such as that to
the trunk.

-Miles

-- 
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.

Re: Window background color

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Sun, 5 Oct 2008 23:47:39 -0400
> 
> How does one set the background color of a window?

You can't, AFAIK.

> I use `face-remapping-alist' to define a `default' face for a buffer,  
> with a specific background color.  This works fine unless the buffer  
> is small and does not fill the whole window, or if I scroll to the  
> end.  The area between the last line of the buffer and the bottom of  
> the window is drawn in the frame's background color, rather than in  
> the background color assigned with the default face in that buffer.

That's the expected behavior.

> Would it be sensible to change clear_frame_area to establish the
> right background color, i.e. the one associated with the default
> face appropriate for the buffer shown in the window
> (updated_window), and only default to the frame's background?

I wouldn't do that, at least not now now, since this is how Emacs
behaved since the introduction of faces, and we are in feature freeze.

Re: Window background color

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

On 6 Oct 2008, at 00:06, Miles Bader wrote:
>
> In my "tiling" branch, I've fixed some of that by adding a "clear  
> window area"
> operation that can do window-specific handling, and changing  
> appropriate
> callers to use that.

That would provide a solution - can you make the specific patches  
available?
(I had a look at your branch if that's the one on  
arch.savannah.gnu.org. There's a lot of changes and I couldn't find  
these ones.)

> Maybe I should merge some of the more generic changes such as that to
> the trunk.

... perhaps a 23.2 (or "feature") branch could be started so that such  
changes can be merged early rather than late. See also:

On 6 Oct 2008, at 00:11, Eli Zaretskii wrote:

> I wouldn't do that, at least not now now, since this is how Emacs
> behaved since the introduction of faces, and we are in feature freeze.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]