Re: Mode-line face bug

Re: Mode-line face bug

[Richard Stallman]

    ,----
    | Emacs.mode-line.attributeBackground:    #fbf8f1
    | Emacs.mode-line.attributeForeground:    #101010
    `----

    but I don't have such settings in my ~/.Xresources.

The window manager makes those, but you've identified an Emacs bug.
The bug is that, for frames other than the first,
the X resources override your customization:

    (custom-set-faces
      ;; custom-set-faces was added by Custom.
      ;; If you edit it by hand, you could mess it up, so be careful.
      ;; Your init file should contain only one such instance.
      ;; If there is more than one, they won't work right.
      '(mode-line ((t (:background "#00f8f1" :foreground "#1010ff" :box (:line-=
    width -1 :style released-button)))))
     )

Can someone please fix that, then ack?

Re: Mode-line face bug

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     ,----
>     | Emacs.mode-line.attributeBackground:    #fbf8f1
>     | Emacs.mode-line.attributeForeground:    #101010
>     `----
>
>     but I don't have such settings in my ~/.Xresources.
>
> The window manager makes those, but you've identified an Emacs bug.
> The bug is that, for frames other than the first,
> the X resources override your customization:
>
> Can someone please fix that, then ack?

The behavior where X resources override Custom (and all other Elisp
face settings) seems to have been around since forever --- it can be
seen in Emacs 21 --- and there is no easy clean way to fix it.

One possibility is for the relevant code in faces.el to look for a
'theme-face, and not apply X resources if so.  This is a kludge since
the faces code should ideally be independent of custom, but maybe it
will suffice for now.

Another possibility is to stop the window manager from automatically
setting a face resource for the mode-line.  There would then be no
problem with the convention that X resources override Elisp, since X
resources would be set by the user.

I don't know how to do this, though.  In the first place, why does the
window manager automagically set the mode-line face resource?

Re: Mode-line face bug

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Can someone please fix that, then ack?
>
> The behavior where X resources override Custom (and all other Elisp
> face settings) seems to have been around since forever --- it can be
> seen in Emacs 21 ...

So we obviously don't need to anything about it before the release.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Mode-line face bug

[Richard Stallman]

    Another possibility is to stop the window manager from automatically
    setting a face resource for the mode-line.  There would then be no
    problem with the convention that X resources override Elisp, since X
    resources would be set by the user.

That is an interesting way of looking at it.  I have asked the GNOME
developers to turn off the setting for mode-line, for other reasons.
However, the theme manager also makes settings for other faces, such as
scroll-bar, so the problem would still exist.

It could be that the theme-based settings for other faces won't bother
many users, so few will try to override them by customization.
If so, the remaining problem would not bother people very much.
It would still be a problem, but less urgent.

However, that's academic, because even if the GNOME developers listen
to us, it will take a long time for corrected versions of GNOME to
replace the current ones.  So we need a fix for this now, even if we
won't need it badly 3 years from now.

Here is an idea.  When a face attribute is set by customization,
set a flag to record that fact.  That flag will cause the X resource
to be ignored for that attribute.

Do you agree that is feasible?  Can you implement it?

Re: Mode-line face bug

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Here is an idea.  When a face attribute is set by customization,
> set a flag to record that fact.  That flag will cause the X resource
> to be ignored for that attribute.
>
> Do you agree that is feasible?  Can you implement it?

Like I mentioned, customized faces have a `theme-face' property, which
can be used for this.

Re: Mode-line face bug

[Richard Stallman]

    > The behavior where X resources override Custom (and all other Elisp
    > face settings) seems to have been around since forever --- it can be
    > seen in Emacs 21 ...

    So we obviously don't need to anything about it before the release.

Bugs that bother users are important regardless of how long they
have existed.

Re: Mode-line face bug

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > Here is an idea.  When a face attribute is set by customization,
> > set a flag to record that fact.  That flag will cause the X resource
> > to be ignored for that attribute.
> >
> > Do you agree that is feasible?  Can you implement it?
> 
> Like I mentioned, customized faces have a `theme-face' property, which
> can be used for this.

I've checked in a fix along similar lines.

Re: Mode-line face bug

[Leo]

On 2007-03-11, Chong Yidong said:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> > Here is an idea.  When a face attribute is set by customization,
>> > set a flag to record that fact.  That flag will cause the X resource
>> > to be ignored for that attribute.
>> >
>> > Do you agree that is feasible?  Can you implement it?
>> 
>> Like I mentioned, customized faces have a `theme-face' property, which
>> can be used for this.
>
> I've checked in a fix along similar lines.

I confirm it is indeed fixed.

BTW, does that mean this change is redundant?

2007-02-06  Chong Yidong  <cyd@stupidchicken.com>

	* faces.el (face-set-after-frame-default): Compile attributes to
	be set by frame parameters before merging in X resources.

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

Re: Mode-line face bug

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> BTW, does that mean this change is redundant?
>
> 2007-02-06  Chong Yidong  <cyd@stupidchicken.com>
>
> 	* faces.el (face-set-after-frame-default): Compile attributes to
> 	be set by frame parameters before merging in X resources.

I don't think so.

Re: Mode-line face bug

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > The behavior where X resources override Custom (and all other Elisp
>     > face settings) seems to have been around since forever --- it can be
>     > seen in Emacs 21 ...
>
>     So we obviously don't need to anything about it before the release.
>
> Bugs that bother users are important regardless of how long they
> have existed.

With that logic, we'll never have a release.

I didn't say the bug is not important -- I just claim it is far more
important to make a release!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Mode-line face bug

[Richard Stallman]

    > Here is an idea.  When a face attribute is set by customization,
    > set a flag to record that fact.  That flag will cause the X resource
    > to be ignored for that attribute.
    >
    > Do you agree that is feasible?  Can you implement it?

    Like I mentioned, customized faces have a `theme-face' property, which
    can be used for this.

Thanks for fixing it.

Re: Mode-line face bug

[Richard Stallman]

    Actually this is not what this is about. There seems to be a confusion
    with the splash screen. The point here is that the *scratch* buffer is
    empty. (Where it is in the buffer list does not matter.) You could
    argue that there is no point in a *scratch* buffer, if desktop
    reverted a session. But in that case it shouldn't exist at all.

I stand corrected.

I agree that there is no reason not to put the usual scratch buffer
message into the scratch buffer.  So I guess this change should be made.

Glenn, would you please install your startup.el patch?

Re: Mode-line face bug

[Glenn Morris]

Richard Stallman wrote:

> I agree that there is no reason not to put the usual scratch buffer
> message into the scratch buffer.  So I guess this change should be made.
>
> Glenn, would you please install your startup.el patch?

done