Re: Faces applies to new frames

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Typo.  I meant to use the font attribute of the default face in the new
> frame:

> *** trunk/lisp/faces.el.~1.416.~	2008-06-28 22:14:35.000000000 -0400
> --- trunk/lisp/faces.el	2008-06-29 11:11:35.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 frame)
> +       (set-frame-parameter frame 'font (face-font 'default frame)))
>       ;; Apply the attributes specified by frame parameters.  This
>       ;; rewrites parameters changed by make-face-x-resource-internal
>       (dolist (param apply-params)

> The point is that the default face in the new frame specifies a font
> (based on its family, slant, and weight attributes) that may differ from
> the `font' frame parameter.  In that case, it's the former we should
> use.  The call to face-font returns a font object consistent with the
> attributes of the default face.  Any font-parameter supplied by the user
> further overrides this.  Make sense?

Yes, it makes a bit more sense, except that now I wonder why this
code would be needed at all?  Isn't the `font' frame-parameter
automatically always kept up-to-date with the font of the
`default' face?  If not, I think it should, and hence it should be done
elsewhere so that it's also true when we later change the default face
via `set-face-attributes' or something like that.

>> It appears to read some of the settings for the `default' face from
>> face-new-frame-defaults and then applies them to the `default' face on
>> the current frame.  This seems both useless and dubious:
>> face-new-frame-defaults is presumably obeyed elsewhere already, and
>> why should we only play with the `font' part of the `default' face?

> Not sure.  It's possible that some of the operations in
> face-new-frame-defaults need some information in the default face,
> e.g. to figure out column widths, even if that information is later
> revised.

I do not follow.  AFAIK, there are no operations in
face-new-frame-defaults, and I have no idea what column width come
into play.  Can you give a concrete example, maybe?

>> - apply defface
>> - apply Xresources
>> - apply face-new-frame-defaults
>> - apply frame-parameters
>> 
>> The first 3 will always return the exact same result for every frame on
>> the same terminal (at least, if we ignore frame-specific Xresource
>> settings).
>> 
>> So I don't see why we can't just precompute this result at
>> terminal-creation time and store it directly in face-new-frame-defaults
>> (after making this variable terminal-local).

> Now I see your point.

> The problem with this proposal is that if Lisp code changes the defface
> spec, we would need to update this value by recomputing X resources,
> face-new-frame-defaults, etc etc.  Since we allow Lisp code to access
> defface specs as Lisp lists instead of using accessor functions, I don't
> see how to handle this.

I don't understand how that's relevant: the same problem exists
already today, doesn't it?


        Stefan