Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Gregory Heytings]

> > Of course I did.  That you did not read it is another thing.
>
> You did not.  The only real technical argument you put forth was some 
> nonsense about FOR_EACH_TAIL being slow.

"Nonsense", again?  Thank you!

> My change did not change any behavior, which is why I saw no purpose 
> discussing it at all.

It is telling that you "see no purpose" in discussing a change to code 
that was agreed upon after 300 posts in a bug report.

> All it did was rename and redocument a Lisp variable to remove 
> technicalities that are not of interest to our users.

That variable is of no interest whatsoever to our users.  It is there only 
for debugging purposes, and is once again only meant to be used by the few 
users who understand subtle technicalities in the face realization code.

> > And you revert without even reading or replying to the detailed 
> > explanation why that "improvement" was wrong.
>
> I replied.

Aha.  That's your understanding of a "discussion", then: you say 
something, and act immediately, without waiting for a potential answer. 
And then claim that there was a "discussion" because you said something. 
Oh, in fact no, that's not even what happened: you reverted before saying 
anything.

> > That's wrong.  And you would have understood this if you had read the 
> > detailed explanation why your "improvement" is wrong.
>
> Really? What if a font entity is there, not a font spec? Or a font spec 
> from the Haiku font dialog?

You would not ask that question if you had read the explanation in 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#331.  And the fact you 
ask that question shows that you did not read it.

> 1. Nobody will ever remember to update the variable after the enum is 
> changed.

The relevant parts of that enum have not changed at all since they were 
introduced fifteen years ago.

> 2. Someone will fill the bitmask with random bogus that happens to do 
> nothing now, but will start to do something unexpected ``some time 
> later''.

Nobody should do that.  The docstring clearly said: "There is no reason to 
change that value except for debugging purposes."

> 3. The maximum value of enum font_property_index will exceed what can 
> fit in 29 bits at some point in the future.

Oh yes, I see.  FONT_SPEC_MAX is (and has always been) 15, but clearly, 
for a reason that hasn't happened in the past fifteen years, "at some 
point in the future", it will become 30, and that will be problematic on 
32-bit computers.  And you tell me that what I write is "nonsense".

Anyway, I don't want to deal with this anymore.  I probably spent about 50 
hours on that bug, that's more than enough.