Re: Not protecting Lisp objects from GC

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 27 Jan 2025 11:46:47 -0600
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If someone suggests a simpler, cleaner change, I might reconsider.
> 
> We are now in a situation where the feature/igc developers are
> protesting vehemently against this, to the extent that there is even
> talk of not merging feature/igc at all.  This is not a good outcome.
> 
> One side in this discussion argue that removing DEFVAR_LISP_NOPRO is
> risk-free, or something close to it, and decreases the risk for GC bugs.
> 
> The other side argues that any change comes with inherent risk,
> especially in a currently poorly understood area like font.c, and that
> keeping what we have is low risk.
> 
> Since this discussion seems to revolve around managing risk in different
> ways, I would suggest the following compromise:
> 
> 1. We install the attached patch on master _as an experiment_, which
>    means that we install it with the understanding that we are keeping
>    the option open to revert it later.  We have used this method in the
>    past to good effect.

This patch reverts a fix for a real and unrelated bug: changing the
font style table is not reflected to the relevant Lisp variables,
which confusingly keep the old outdated values.  So the patch as you
show it is wrong, IMO.  It certainly isn't simpler and cleaner than
what was proposed earlier.

If you insist on removing the macro in the non-MPS build, let's please
do that on the igc branch, but without reverting the bugfix I mention
above.  That bugfix is unrelated to the removal of the macro.  The
change will then land when we merge the branch.

> 2. We agree to re-evaluate the patch before the fist pretest for Emacs
>    31.1, or even sooner, keeping the option open to revert it if needed.
> 
> 3. If there is no trouble with the patch, we leave it as is.  The
>    pretest will give us more opportunities to get this change tested in
>    various configurations.
> 
> 4. We keep the option open to revert it at any point during the pretest
>    also, if it turns out to be causing issues.

Unfortunately, this practice doesn't work with the code in question.
The experience with font.c and fontset.c code is that changes there
which cause trouble are discovered many moons after they were made.
So let's not rely on this technique because it will not work.  If you
insist on changing that against my objections, I agree, under protest,
to making the change now on the branch.

(I still think that this is quite a mountain out of a molehill.)

> I hope that this could make everyone happy, and let us get back to our
> regularly scheduled hacking.

Since you asked: this kind of unfriendly pressure cannot possibly
leave me happy.  But I don't want to keep this going any longer,
either.