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

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Amazing.  I thought this exhausting discussion was over, but no, Po Lu
> came and "improved" the code that was agreed upon only a couple of
> hours after it was pushed, disregarding this entire discussion, the
> docstring of the variable that the commit introduced, the commit
> message, and without asking any questions.  How can that be right, how
> can that be acceptable?

I did not change the behavior of that commit at all.  That can hardly be
called ``disregarding this entire discussion''.

> Po Lu's commit said "there is no reason any user should have to think
> about bitmasks" even though the docstring said "there is no reason to
> change that value except for debugging purposes."  (Of course, that
> sentence was also removed from the "improved" version of the
> docstring.)

So are you saying that users are not supposed to debug Emacs?  Then
let's stop distributing etc/DEBUG, to save cycles when unpacking Emacs!
While we're at it, let's also strip Emacs binaries by default.

> 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?
Premature optimization is the root of all evil.

If you think that is likely to lead to a real performance problem, then
you're more or less 60 years out of touch with the performance of modern
computer technology.  So, please, demonstrate that searching for a
symbol through a list with 3 elements leads to a performance problem.

Can you find any other ``debug variable'' that is a bitmask?  What if we
add different font spec attributes in the future, that bump the index
past 29 bits?  And why should Lisp have to know about bitmasks at all?

> The name of the variable was changed, and the docstring was
> "improved", and became completely wrong.  It is simply untrue that
> this is a list of attributes that Emacs will "ignore when realizing a
> face", or in fact that this changes anything fundamental in the way
> Emacs realizes faces.

Then I guess you only read the first sentence of the doc string.  Read
it again, specifically:

  tells Emacs to ignore the `:weight', `:slant' and `:width' face
  attributes when searching for a font and an exact match could not be
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  found for the font attributes specified in the face being realized.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What is inaccurate about that statement? 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?)

But anyway if you respond with some more nonsense, don't expect me to
reply.  Please demonstrate:

  - There is a real performance problem with searching through a list
    with three elements upon face realization.

  - My change actually changes the behavior of the variable, leading to
    this bug not being fixed.