I have been using haskell-mode for some time now with no problems.
Recently emacs has started to hang for quite a while whenever I type in something in haskell-mode, say 10-15 seconds, and then returns to "normal". I can navigate around and switch buffers normally, but typing (in the haskell buffer) somehow halts emacs completely.
I don't recall changing anything, haskell- or emacs-wise, before this started occuring.
Moreover, it seems very difficult to track down. I have the following error message, but I'm not even sure that it related to this issue:
Error during redisplay: (jit-lock-function 1285) signaled (error
"Error in syntax_table logic for to-the-end intervals")
The freezes/hangs only occur in haskell-mode, everything else seems to act normally.
Is there a way I can find out what is blocking, and from there probably get closer to figuring it out?
I think it could be the same as this bug. It has been fixed (in this commit) but I don't think any released versions have the fix, so you'll have to either download the latest source from git or apply the patch manually.
Related
I've been trying to set up the Scala layer and the Metals backend for spacemacs. I am relatively new to spacemacs and completely new to Scala. Quickly some problems, for which I have no idea how they can be connected to the Scala layer, arised. Firstly I got an error saying "package eldoc not initialized in layer java" despite the fact that I had no java layer installed at the time. I managed to resolve that one by installing the java layer and then deleting a line saying "eldoc" in the file at layers/+lang/java/packages.el.
Afterwards another problem appeared, which I still haven't managed to solve, namely now I get the following message upon opening spacemacs:
(Spacemacs) Error in dotspacemacs/user-config: Symbol’s value as variable is void: lsp-server-install-dir
I googled right about everything about this error and found absolutely no other reports of such a problem and nothing close to a solution.
I tried experimenting with disabling certain layers in .spacemacs and commenting out the lines I added before the problem appeared, but nothing changes or even more errors and warnings appear.
I am not sure if this is in any way connected, but after trying to install the Haskell IDE Engine into spacemacs a few months back, I got a warning, which still appears whenever I start spacemacs, saying:
wrong-type-argument stringp nil
This second problem seems to be harmless, so after a few days I gave up on trying to solve it and have been using spacemacs normally until now. This new error about lsp-server-install-dir, however, seems to be more urgent and spacemacs shows a red line at the bottom saying that it might not work correctly.
Every time I kill a buffer containing an executing process in Emacs I get an annoying ~2 second delay before my interaction continues. And when that happens I get the message
error in process sentinel: Selecting deleted buffer
The tricky problem is that it only happens in my Emacs configuration and not in Vanilla Emacs. I'm guessing the delay happens because of an extra hook or advice activated in one or some of my modules loaded.
Does anybody recognize the error message and know which hook or advice that might be causing this problem? I've tried searching the web without any luck.
I'm talking specifically about Pymacs, but this would be useful to know if anything like that happens in other circumstances.
The problem: when something goes wrong in Pymacs, it will no matter what try to restart itself, and especially so when it fails to start at all. But somehow it is adding a hook to run before any file (not necessary in Python mode) should be saved or closed. So, what happens - it becomes impossible to shut down Emacs in a "nice" way - I can only terminate the process from shell, because Pymacs would enter an infinite loop: when saving a file - it would try to restart itself, fail and prevent the file from being saved - since it failed, it'll prompt to restart - no matter if I answer yes or no to restarting it, it will fail and ask again to restart itself.
M-x unload-feature doesn't help because it can't unload it (because .emacs loads it). I'm not sure at all by the way if the unload-feature can ever do anything meaningful :| I was trying to evaluate (setq kill-buffer-hook nil) but this didn't seem to help either. Perhaps there are some other hooks? Is there a way to force unload-feature to actually do something? In this situation I'd prefer save file and crash, then infinite loop and no crash, but file not saved situation.
There's an external library I'm working with that frequently pegs my CPU. I'd like to help the author fix it (as I really like the library), but I don't know how to debug the crash properly.
Any tips for debugging Emacs lisp? Bear in mind when it crashes Emacs doesn't work anymore and I have to kill it (so solutions within Emacs itself might not be helpful).
Edit: I should clarify that it is byte-compiled, and this issue doesn't always happen for others, so it may be specific to my architecture/init files. It is definitely related to this library though.
First, always debug the uncompiled version of a Emacs-Lisp program, unless you're convinced the problem is introduced by the byte-compiler.
Second, if the code is hanging Emacs then the code is probably in an infinite loop with inhibit-quit bound non-nil. So the first thing to do is go through the source for the library and change all inhibit-quit references to something else so that C-g will work to stop the looping. After that, load up the library, set debug-on-quit to t and you should get a nice debug trace when you press C-g that shows you where the code is looping. From there, debugging the problem should be as straightforward as debugging any other infinite loop.
I must be in the habit of leaving the mini-buffer in the middle of a command. From there I will change buffers and continue working. Later (sometimes much later) I'll notice that I had a command dangling incomplete in the mini-buffer. If I go to cancel it with a C-g, Emacs will often swap buffers in my open windows to an earlier state.
I suppose this may be a feature, but in my flow of work I find it rather annoying. Is there a way to stop this behavior or prevent it from happening, such as a warning that There is an incomplete command?
I think that the answer to another question will help you solve this. It can be an annoying behavior, but the solution limits some of the flexibility found in Emacs.
The answer is: How can I prevent the mini-buffer from displaying previous commands in Emacs? (I call it stop-using-minibuffer).