bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#17532: 24.4.50; Options > `set-frame-font' does not work as document


From: Eli Zaretskii
Subject: bug#17532: 24.4.50; Options > `set-frame-font' does not work as documented
Date: Wed, 21 May 2014 21:46:42 +0300

> Date: Wed, 21 May 2014 11:03:44 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 17532@debbugs.gnu.org
> 
> > > > But that doesn't cover future frames, either.  It only affects the
> > > > existing GUI frames, per the doc string (and the code, which see).
> > >                        ^^^^^^^^^^^^^^^^^^
> > >
> > > Where are you getting this?  `C-h f set-frame-font' says clearly:
> > >
> > >    Also, if FRAME is non-nil, alter the user's Customization settings as
> > >    though the font-related attributes of the `default' face had been
> > >    "set in this session", so that the font is applied to future frames.
> > >
> > > One of us seems to be sorely missing something. ;-)
> > 
> > You are missing the previous sentence of the doc string.
> 
> No, I was not missing that previous sentence: 
> 
>   "If FRAMES is non-nil, it should be a list of frames to act upon,
>   or t meaning all graphical frames."
> 
> Where does it say that only existing frames should be affected?

It says that to me, because it doesn't mention future frames.  Now I
made that clear by saying that explicitly.

> > > A face, including face `default', is not something that is frame-specific.
> > 
> > Faces are _always_ frame-specific in Emacs.  That includes the
> > 'default' face.  Thus, changing the 'default' face does not imply the
> > change affects all frames, let alone future frames.
> 
> That's not my understanding.

Your understanding is wrong.

> A face is defined independently of any place it might be displayed,
> including any frame.
> 
> A face _attribute_ can have different values for a given face on
> different frames.

That's what I meant: the 'font' attribute of the 'default' face can be
different on each frame.

> That does not mean that the face itself is different.

You are playing word games.  I explained above what I meant by saying
"faces are frame-specific".  My point still stands: it is a legitimate
use case to have the default font different on different frames.

> A face's default attributes are what apply to newly created frames.
> Changing the default font of a face, in particular, should affect new
> frames.  And particularly for face `default'.

That's not how Emacs works.  If it did, you wouldn't need
default-frame-alist.

> What's more, the doc says clearly that a `t' value for `set-face-attribute'
> parameter FRAME " sets the attributes for all existing frames, as well
> as for newly created frames."

But set-frame-font doesn't call set-face-attribute with that argument
set to t, it calls set-face-attribute separately for each frame
returned by frame-list.  So only on those frames we modify the font of
the default face, and of course those frames are only those that exist
at the moment of the call.

>   The following commands and functions mostly provide compatibility
>   with old versions of Emacs.  They work by calling `set-face-attribute'.
>   Values of `t' and `nil' for their FRAME argument are handled just like
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   `set-face-attribute' and `face-attribute'.  The commands read their
>   ^^^^^^^^^^^^^^^^^^^^
>   arguments using the minibuffer, if called interactively.
> 
> Why you would think that `set-face-font' should not do like this doc
> says and should be an exception to the rule that `t' affects newly
> created frames as well as existing frames, is beyond me.

I just read the code, and it tells a different story.

> > The very next bullet is about a different method of changing the font,
> > so it's not really relevant to what this first bullet describes.
> 
> A different method of doing the same thing: changing the font for
> new frames!

That's your interpretation; the text doesn't say that.

> the doc is pretty much right in suggesting that new frames are also
> affected; the product is wrong in not respecting that.

"The product" never did.  In fact, the argument FRAMES appeared only
in Emacs 24.1; before that, you couldn't even set the font for more
than just the selected frame.  I wish it had stayed that way, but
that's me.





reply via email to

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