emacs-devel
[Top][All Lists]
Advanced

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

Re: Faces applies to new frames


From: Chong Yidong
Subject: Re: Faces applies to new frames
Date: Sun, 29 Jun 2008 00:30:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Stefan Monnier <address@hidden> writes:

> Basically, I think that frame parameters should generally take
> precedence since they may really be set on a frame-by-frame basis.

The trouble is that the `font' frame parameter interferes with the
normal semantics of Lisp faces.  It should always be defined for each
frame, so if it always takes precedence, there would be no good way to
make changes to the default face apply to new frames, because any change
would be overriden by `font'.  And, I don't think it's easy to calculate
what `font' ought to be ahead of time.  That's why I suggested setting
`font' in face-set-after-frame-default, after processing the defface
spec.

By the way, a more limited change than what I suggested earlier seems to
DTRT: with this, calling make-frame with a `font' frame parameter seems
to DTRT, as do other tests of set-face-attribute I tried out.

*** trunk/lisp/faces.el.~1.416.~        2008-06-28 22:14:35.000000000 -0400
--- trunk/lisp/faces.el 2008-06-29 00:13:28.000000000 -0400
***************
*** 2056,2061 ****
--- 2056,2065 ----
                (make-face-x-resource-internal face frame))
            (internal-merge-in-global-face face frame))
        (error nil)))
+     ;; The face specs may specify a different default font.  Save this
+     ;; in the `font' frame parameter.
+     (when (face-font 'default)
+       (set-frame-parameter frame 'font (face-font 'default)))
      ;; Apply the attributes specified by frame parameters.  This
      ;; rewrites parameters changed by make-face-x-resource-internal
      (dolist (param apply-params)

> This implies that set-face-attribute should probably store global
> settings elsewhere than on default-frame-alist.  It sounds like
> face-new-frame-defaults would be a good place for that instead (th0o
> this is only based on its name)

That's currently the case.

> Here's my current understanding of the various places where we store
> face info:
>
> - face-new-frame-defaults, should be global and seems to only ever
>   contain "unspecified".  I.e. pretty much unused.

face-new-frame-defaults is where set-face-attribute stores changes that
are supposed to be applied to faces on furture frames.  So if you do

  (set-face-attribute 'default nil :slant 'italic)

Then you'll see that the `default' entry in face-new-frame-defaults
contains `italic' in its slant attribute.

> 1 - rule out frame-specific Xresources settings
> 2 - make face-new-frame-defaults terminal-local, so it's initialized at
>     terminal-creation time by applying defface and Xresources settings.
> 3 - rule that "global" set-face-attribute settings only apply to future
>     frames on the same terminals (i.e. they're not truly global any
>     more), so it can work by modifying the terminal's
>     face-new-frame-defaults and it will hence take precedence over
>     customize (i.e. defface) and Xresources settings.

I don't see how this makes sense.  As long as each frame is allowed to
have its own face settings, the current dance in face-new-frame-defaults
will be necessary each time we create a new frace.




reply via email to

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