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.
Related
Whenever I try to save my emacs file, it prompts me "file has changed since visited or saved. Save anyway? (yes/no)". I tried "diff buffer-with-file" but it says there's no difference. I'm suspecting this is happening because I'm using a virtual machine with shared file. Anyway, I want to silence this error, and save without prompt. Any solutions?
If this is only happening for a particular file in a particular Emacs instance, you can try M-x revert-buffer to replace the buffer with the contents of the file. That should reset the timer to what's on disk. Of course you will lose any unsaved changes, but you say you have none.
If this doesn't work, or you are getting this error for every file every time you run Emacs, you are in bigger trouble than I know how to diagnose.
SingleInstance force
is supposed to prevent the popup when I tell the script to reload... but it doesn't. I'm still getting the warning that a copy of the script is already running. Thoughts?
Without seeing your code, there are a few things I can think of that might be interfering. The first is that there may be a typo. Please verify that it is exactly #SingleInstance force. Another thing could be that it is not placed near the beginning of the script; possibly after a Return. Finally, from the help file,
AutoHotkey relies on the title of the script's main window to
identify other running instances of the script.
Is this script calling another script or is there anything the might affect the script name? If none of these things helps, it might be a good idea to post your code or at least a portion of it so we can better see what's going on.
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 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.
Recently I have been having an issue with desktop save mode where it will not actually save my desktop. In the echo bar it says "Error while saving the desktop..." After typing no it says "Opening output file: no such file or directory, then gives the location to the path of the file". After saving a .emacs.desktop file then restarting emacs I noticed that it is saving the buffer locations in that file but is not loading that file. Thanks. Also I am not sure what has caused this to happen as it was working a couple weeks backs and nothing has changed that should make a difference.
The only thing i have in my .emacs for the desktop mode is
(desktop-save-mode 1)
Looking at the code for desktop.el here, it looks like the error is bubbling up from desktop-kill, which runs when you exit Emacs. The first thing I'd try is to check that the directory where it tries to save the desktop is sane.
Looking at the code in desktop-kill, it only tries to do anything if the variable desktop-dirname is non-nil. But that only gets set when you run M-x desktop-save for the first time: are you sure that it's set to something sensible? To check its value quickly, you can type M-: desktop-dirname RET and it should appear as a string in the message area.
If the directory is something sensible (the directory exists and you can write to it...), then I'm not sure. You'll probably have to give more information to get a solution, and it's not really clear that it's an ideal question for StackOverflow.
i should hazard that you get this error by creating a shortcut in the windows start manual via clicking addpm.exe in the ...\emacs-version\bin\ folder.
you can further modify the shortcut. go to its property->shortcut tab, you will find that the Target has value like ...\emacs-version\bin\runemacs.exe, while Start in is void. try to fill Start in with the corresponding folder ...\emacs-version\bin (actually most directories would be fine, just don't leave it blank), then everything is fine. still, the machanism behind this remains unclear to me.
or you could always creat your own shortcut manually, only make sure that the target is runemacs.exe, not any other exe file.