GNU bug report logs - #75521
scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 75521 <at> debbugs.gnu.org, pipcet <at> protonmail.com
Subject: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX
Date: Tue, 14 Jan 2025 05:30:02 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 13 Jan 2025 21:09:02 +0000
> Cc: pipcet <at> protonmail.com, 75521 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> Date: Mon, 13 Jan 2025 20:01:24 +0000
> >> Cc: pipcet <at> protonmail.com, 75521 <at> debbugs.gnu.org
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> >> I'm curious why this was considered worth optimizing in the first place.
> >> >
> >> > What is the optimization here? DEFVAR_LISP_NOPRO or font_style_table?
> >>
> >> I was thinking of DEFVAR_LISP_NOPRO:
> >
> > AFAIU, it's there to avoid protecting something that is already
> > protected.  staticvec[] is a static vector, so wasting slots there is
> > best avoided.
> 
> Yes, indeed, but that seems like an optimization that is not worth
> doing.  Not these days, at any rate.

If you try to staticpro too many variables, the build will fail
because Emacs runs out of space in staticvec.  Not everyone knows what
to do in this case, and it's an annoyance when this happens.  So I
would not say so easily that it's an optimization not worth doing, no.

> It complicates the code, leading to confusion (case in point: this long
> thread where many cycles were spent discussing it), and the performance
> gains are not likely to even be measurable.

That's normal in Emacs.  Some stuff is complex, and given enough
comments can be dealt with without too many problems.

And this thread is in a way a self-inflicted shoot-in-the-foot
problem: we could have left the code alone, as it works for us for
decades without any visible problems.

> Note that with MPS, DEFVAR_LISP and DEFVAR_LISP_NOPRO are equivalent.

When the igc branch lands, this will be a non-issue, yes.  One more
reason not to waste too much effort on this code now.  But since the
genie is out of the bottle, we must.

> So by getting rid of DEFVAR_LISP_NOPRO, we would reduce the delta
> between igc and master as a nice bonus.

Why do we need to reduce the delta? what does that get us?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.