Looks like you have nailed it. If I now think about it, this has happened only after an error (but not always after an error).
Last time this happened was after I was trying to intentionally generate an error by evaluating
(string-match-p "." nil)
That was part of testing out some elisp, but that's a different story. I basically needed to try some snippet that would generate error and I came up with above.
I later find that the above causes emacs to freeze when using my config, but not in emacs -Q (master branch).
I can get out of the emacs freeze by hitting C-g. But then I get:
Entering debugger...
Error during redisplay: (jit-lock-function 1619) signaled (args-out-of-range 0 1622)
Error during redisplay: (jit-lock-function 2119) signaled (args-out-of-range 0 2131)
Error during redisplay: (jit-lock-function 2619) signaled (args-out-of-range 0 2684)
Error during redisplay: (jit-lock-function 3119) signaled (args-out-of-range 0 3364)
help-function-arglist: End of file during parsing
Error in post-command-hook (global-font-lock-mode-check-buffers): (quit)
Error during redisplay: (jit-lock-function 1619) signaled (quit)
Error during redisplay: (jit-lock-function 1620) signaled (quit)
Quit [8 times]
So then I repeated generating the above error to figure out what in my config is causing it (still haven't figured it out).
The strange thing is that
(string-match-p "." nil)
generates proper backtrace as expected when using my config:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("." nil)
eval((string-match "." nil) nil)
eval-_expression_((string-match "." nil) nil)
funcall-interactively(eval-_expression_ (string-match "." nil) nil)
call-interactively(eval-_expression_ nil nil)
command-execute(eval-_expression_)
Note that I simply replaced string-match-p with string-match. So error backtrace generation has been working fine for me, except that "(string-match-p "." nil)" triggers some bug in my config that causes emacs to freeze, and that's most likely what's wiping the bindings, except that I cannot recreate the binding loss scenario.
In one of such intentionally generated error trials, I lost all the bindings. (I have no idea was help-function-arglist has to do in this. I grepped my config, packages, but couldn't figure out what that has to do with error caused by using nil instead of a string.)
On Mon, Jul 11, 2016 at 10:43 AM Eli Zaretskii <
address@hidden> wrote:
One of those (or something similar) done by some code that fails to
unwind-protect itself, and so leaves these values behind when you type
C-g or some other error is signaled.