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

[Gregory Heytings]

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