[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Re: scroll-bar face gets changed in a new frame]

From: Leo
Subject: Re: address@hidden: Re: scroll-bar face gets changed in a new frame]
Date: Sun, 04 Feb 2007 01:25:16 +0000
User-agent: No Gnus v0.6, Emacs/ (2007-02-04), Fedora 6 gnu/linux

On 2007-02-04, Chong Yidong said:

> Richard Stallman <address@hidden> writes:
>> Would someone please investigate this and DTRT?
> The problem is in face-set-after-frame-default.  The function merges
> in the X resources, then initializes attributes from frame parameters.
> However, if there is a scroll-bar X resource present, the call to
> make-face-x-resource-internal will chang the scroll-bar-* frame
> parameters in the process of changing the scroll-bar face.  Therefore,
> any previously-applied frame parameters are lost.
> I think one fix is for face-set-after-frame-default to first construct
> a list of frame parameters to be applied (based on the new frame's
> frame-parameters and/or the face's value for new frames), then wait
> until after the call to make-face-x-resource-internal before applying
> these changes.  See the attached patch.
> By the way, the symbol inhibit-default-face-x-resources seems to be a
> no-op; it is called as
>  (when (not (equal face 'default))
>    ...
>    (when (and (memq window-system '(x w32 mac))
>      (or (not (boundp 'inhibit-default-face-x-resources))
>          (not (eq face 'default))))
>      (make-face-x-resource-internal face frame)))
> However, since face is never `default' inside the `when' form, the
> enclosing `or' statement is always t, regardless of whether or not
> inhibit-default-face-x-resources is bound.  I think this symbol was
> introduced to solve a similar problem, and it can be removed if the
> proposed fix is applied.

I confirm it fixes the bug.

Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]