GNU bug report logs -
#75521
scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX
Previous Next
Full log
Message #115 received at 75521 <at> debbugs.gnu.org (full text, mbox):
"Eli Zaretskii" <eliz <at> gnu.org> writes:
>> 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.
Running out of NSTATICS is not and never has been a significant problem.
If you want to change the error message (which seems quite clear, to
me), feel free to, but saying that we shouldn't staticpro variables that
need to be staticpro'd because we might have to bump NSTATICS is too
ridiculous an argument to entertain.
(On this system, NSTATICS is 2048, but there are only 304 explicit
staticpro calls in the Emacs code base, plus 636 DEFVAR_LISP* calls.
We're very, very far from the point where we need to consider bumping
it.)
>> 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.
Keeping unnecessary and broken complexity because "it works for us" (it
doesn't work for anyone using the API; I assume people tried, failed,
and gave up on Emacs) is not the right thing to do, no.
What went wrong here is quite different: it's a simple problem, it was
discovered and fixed, it took quite a while to get you to understand it,
and then you immediately went into "oh, right, it's a bug, but let's not
fix it" mode.
It's a bug, there's a fix, it simplifies things significantly (lines
starting with "DEF" are magic to make-docfile.c, so we should try to
reduce the number of cases that imperfect parser has to handle).
Describing someone's effort to improve Emacs as "shoot-in-the-foot" is
quite offensive, BTW.
>> 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
^^^^
That's still an "if", IMHO.
> reason not to waste too much effort on this code now. But since the
> genie is out of the bottle, we must.
Saying that improving the Emacs code base is a waste of effort only
makes sense if you think Emacs development will stop soon. Even then,
it's also quite offensive.
>> 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?
It turns the "if" into more of a "when".
I'll stop here. Yet another simple improvement (and bug fix) to Emacs
which was effectively vetoed.
Pip
This bug report was last modified 124 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.