bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings <gregory@heytings.org>]

>> 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.