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

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

bug#54564: 29.0.50; [PATCH] Use gsettings font rendering entries for pgt


From: Eli Zaretskii
Subject: bug#54564: 29.0.50; [PATCH] Use gsettings font rendering entries for pgtk builds
Date: Sat, 26 Mar 2022 09:20:14 +0300

> From: Po Lu <luangruo@yahoo.com>
> Cc: pieter.van.prooijen@teloden.nl,  54564@debbugs.gnu.org
> Date: Sat, 26 Mar 2022 14:07:21 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe I could help if I understood the difficulty well enough.  What
> > exactly is the problem here?  In particular, what is meant by "force a
> > re-creation of the font with the changed parameters"?  How can Emacs
> > "re-create" a font?
> 
> Basically, Emacs needs to close every open font object created by the
> ftcr (or ftcrhb) font driver, and open it again, if that makes any
> sense.

Does the below fit the bill?

   clear_face_cache (true);

Or did you mean to do this only on a single frame (or on specific
selected frames)?  Then looking inside clear_face_cache will tell you
how to do that.

And one more thing: care should be taken if this is done in response
to some async notification, because clearing all the faces will need a
thorough redisplay.  Most probably all the affected frames need to be
marked as "garbaged".

> > AFAIU, this uses gsettings to determine some Emacs font-related
> > functionality.  One aspect that bothers me is whether users will have
> > the means to tell Emacs to ignore those gsettings and use the usual
> > Emacs defaults instead?  I don't think it's a good idea to apply those
> > gsettings unconditionally without letting users override that.
> 
> I think all the gsettings-related behavior is controlled by
> `font-use-system-font'

I don't see any references to that variable in the patch you are
discussing.  And its name and doc string don't seem to give any clue
that it's relevant to this issue.  Is this only for fixed-pitch fonts?

> but if it's not, we could always make it work that way, or add a new
> variable.

Yes, I think so.





reply via email to

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