[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Note on e65c307 breaks font-height
From: |
Eli Zaretskii |
Subject: |
Re: Note on e65c307 breaks font-height |
Date: |
Sat, 04 Jun 2016 13:52:09 +0300 |
> Date: Sat, 04 Jun 2016 11:48:10 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
>
> > IOW, the font selection code was not designed to support what you'd
> > like, not in general. That is why I strongly recommend to just state
> > a specific font of your liking, and move on.
>
> What I did (in the previous century, IIRC) was to select the procedure
> that I then considered best supported by the customization interface.
> Can you point me to a similar interface for the step you propose? IOW,
> I still think that mine is the way a newbie would use.
I don't understand why we are talking about customization interfaces.
I thought the problem was that requesting a font by specifying some of
its attributes doesn't work. Now I'm confused: what problem is at
hand?
> > -- Function: face-attribute face attribute &optional frame inherit
> > This function returns the value of the ATTRIBUTE attribute for FACE
> > on FRAME.
> >
> > And all the other functions in that node accept the FRAME argument.
>
> IIUC none of these bear any relation to the customization interface.
"M-x customize-face" changes the face definitions on all frames, but
you can invoke set-face-attribute with a specific frame to change the
face only on that frame.
> And I still don't see where the customization framework allows or
> suggests to specifiy a face for a frame or for "any" frame.
I don't think it does.
In any case, it looks like a simple question of mine led us aside for
no good reason. Whether faces are or aren't per frame has nothing to
do with the problem at hand.