bug#50338: [Emacs 28.0.50 Trunk] Error running timer ‘jit-lock-stealth-fontify’: wrong-type-argument timerp

bug#50338: [Emacs 28.0.50 Trunk] Error running timer ‘jit-lock-stealth-fontify’: wrong-type-argument timerp

[Jacob Faibussowitsch]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

Hello,

Full error message:
Error running timer ‘jit-lock-stealth-fontify’: (wrong-type-argument timerp [t nil nil nil nil nil nil nil nil])

To reproduce:
1. Build latest trunk
2. Paste the following into some file, lets call it custom-test.el (I couldn’t figure out a better way to do this)
(custom-set-variables
 '(jit-lock-stealth-time 1))
3. Then load this file and open another file which would trigger fortification:
$ emacs -q --load ./custom-test.el ./lorem.py
4. Check *Messages*, the error should come up every second now

I’ve also gotten the following related errors (but don’t know how to precisely trigger them):
- File mode specification error: (wrong-type-argument timerp [t nil nil nil nil nil nil nil nil])
- custom-initialize-reset: Wrong type argument: timerp, [t nil nil nil nil nil nil nil nil]

Reverting to right before commit 50765f3f511d467ff024dda7c84530c759253d18:
Author: Lars Ingebrigtsen <larsi@gnus.org>
Date:   Tue Aug 31 03:04:22 2021 +0200

    Make run-at-time try harder to run at integral multiples

    * lisp/emacs-lisp/timer.el (timer): Add new slot integral-multiple.
    (timerp): Adjust.
    (timer-event-handler): Recompute the delay if requested
    (bug#39099).
    (run-at-time): Mark the timer as recomputable if given a t
    parameter.

    * src/keyboard.c (decode_timer): Adjust.

Seemed to fix it (but I wasn’t able to figure out exactly what about this PR caused the error).

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)


[-- Attachment #2: Type: text/html, Size: 3334 bytes --]

bug#50338: [Emacs 28.0.50 Trunk] Error running timer ‘jit-lock-stealth-fontify’: wrong-type-argument timerp

[Lars Ingebrigtsen]

Jacob Faibussowitsch <jacob.fai@gmail.com> writes:

> Full error message:
> Error running timer ‘jit-lock-stealth-fontify’: (wrong-type-argument timerp [t
> nil nil nil nil nil nil nil nil])

Try saying "make bootstrap".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50338: [Emacs 28.0.50 Trunk] Error running timer ‘jit-lock-stealth-fontify’: wrong-type-argument timerp

[Jacob Faibussowitsch]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

> Try saying "make bootstrap".

Works now, thanks!

On a related note: I pull emacs trunk regularly but rebuild and reinstall maybe weekly so should I always be doing make bootstrap? For reference my current workflow is:

1. $ git pull
2. $ make -j ${nproc}
3. $ sudo make install (gotta love macOS root protecting /usr/local/libexec …)

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

> On Sep 2, 2021, at 11:01, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Jacob Faibussowitsch <jacob.fai@gmail.com> writes:
> 
>> Full error message:
>> Error running timer ‘jit-lock-stealth-fontify’: (wrong-type-argument timerp [t
>> nil nil nil nil nil nil nil nil])
> 
> Try saying "make bootstrap".
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no


[-- Attachment #2: Type: text/html, Size: 2563 bytes --]

bug#50338: [Emacs 28.0.50 Trunk] Error running timer ‘jit-lock-stealth-fontify’: wrong-type-argument timerp

[Lars Ingebrigtsen]

Jacob Faibussowitsch <jacob.fai@gmail.com> writes:

> On a related note: I pull emacs trunk regularly but rebuild and reinstall
> maybe weekly so should I always be doing make bootstrap?

No, a bootstrap is normally not necessary, but the Emacs build system is
far from perfect.  The problem is that if we alter a macro in foo.el,
and bar.el requires foo, then foo.elc will be rebuilt, but bar.elc won't
be.  And this can lead to breakages (as it did in this instance).

But we don't change macros that much, so a bootstrap is seldom necessary.

I think there's an open bug report somewhere about fixing this, but I
don't think anybody has come up with a practical idea here (i.e.,
building a dependency graph in an efficient way).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no