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

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

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

> What kind of development practice is this?  You "improve" code in a
> complex area of the Emacs code base that was agreed upon after a long
> discussion only a couple of hours after it was pushed, without asking
> anyone whether what you want to do is okay?

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

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

How many people will remember to redocument the variable the next time
enum font_property_index is changed? Or when realize_gui_face is
renamed?

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

I replied.

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

> It isn't, and it is not supposed to be modified on a daily basis.

A bitmask is always a nuisance, both for users and developers.
Not all Emacs users write programs in languages that make heavy use
of bitmasks such as C.

> Nobody said the discussion was over (although I was hoping it was).
>
> But what you did is not a "discussion", it is the exact opposite of a
> "discussion": these are misguided changes introduced in the release
> branch _without any discussion_.

Why do I have to discuss so-called ``misguided'' changes to obvious
problems, such as having a bitmask exposed to Lisp?

Once again, here are the problems with having bitmasks exposed to users
(not necessarily just through Lisp, this applies to other extension
languages as well along with some graphics drivers) that have been found
in real life:

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

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

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

The doc string and variable was renamed because they make references to
the inner workings of the font machinery.  Again, who will remember to
change the doc string once the C code is rewritten or changed, possibly
after you and I are both gone, or, god forbid, even dead?  (The latter
is a real possibility with the vast timescales in this project.)