GNU bug report logs - #59347
29.0.50; `:family` face setting ignored

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Fri, 18 Nov 2022 04:58:01 UTC

Severity: normal

Found in version 29.0.50

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca, 59347 <at> debbugs.gnu.org
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Mon, 12 Dec 2022 08:54:16 +0000
>> It is on purpose that that variable was a bitmask and not a list, it is 
>> on purpose that that variable was used in a macro and not in a 
>> function: there is no reason that each face realization in each Emacs 
>> instance should spend unnecessary CPU cycles (a function call and 
>> traversing a list) on a variable that should never (or hardly ever) be 
>> changed, and that was introduced only to help debugging other potential 
>> problems in that subtle area of Emacs' code.
>
> And what was the problem with a list?  How many cycles is traversing a 
> list?  How many time will it take for your CPU to perform everything?
>

My measurements indicate that the "improved" code is ~20 slower in an 
optimized build, and I care about performance.  That's a lot to handle a 
variable that is, in fact, a near-constant.

Once again, that variable isn't supposed to be changed by users.  It is 
there for one purpose: if a user reports a bug about font selection, it 
will be possible to ask them to set that variable to this-and-that value 
(most probably 0 and most-positive-fixnum) to check whether Emacs behaves 
better.

Of course, brave souls can also try to change it, if they want.

>
> So, please, demonstrate that searching for a symbol through a list with 
> 3 elements leads to a performance problem.
>

It is not "searching for a symbol through a list with three elements", it 
is 12 function calls, each of which traverses a list of three elements.

>> and an exact match could not be found for the font attributes specified 
>> in the face being realized.
>
> What is inaccurate about that statement?
>

The post to which you are replying explains in every possible detail why 
that statement is wrong.  That you don't have the patience to read a 300 
posts long bug thread is one thing, that you don't have the patience to 
read a 100 lines long explanation, and bluntly declare that it is 
"nonsense", is another.

>
> Unlike your doc string, it does not need the caller to know about the 
> inner workings of the face code (how many of our users even know about 
> the function realize_gui_face?)
>

And the purpose of that variable is precisely that: making it possible to 
dynamically control an implementation detail.  It is _not_ supposed to be 
set by users who do not know about the inner workings of the face code.





This bug report was last modified 2 years and 160 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.