I've been randomly getting the following error in emacs:
Variable binding depth exceeds max-specpdl-size
...and I've been getting it at very random moments. After researching this, it seems as though some elisp somewhere is recursing too deeply. Are there any strategies for tracking this down? I'm totally at a loss as far as what is actually causing this.
I've gotten some errors indicating something along the lines of infinite recursion with ropemacs (but these are usually Python errors). Could something be misconfigured with ropemacs?
Update: Interestingly enough, I've found that I always get this error if I do a "C-h a" for "speedbar" but not for "rope-".
To track the problem down, you can try this:
(setq max-specpdl-size 5) ; default is 1000, reduce the backtrace level
(setq debug-on-error t) ; now you should get a backtrace
C-h a ; in speedbar
You should get a backtrace upon the error, and at that point, you can track down the offending routine.
I'd also try loading emacs w/out your configuration file (emacs -q), to see if there's something in your .emacs that is affecting things. (I don't get the infinite loop using C-h a). And if it is your .emacs, then the best way I've found to track that down is either binary search (put an error (error "frog") or somesuch in the middle of your .emacs, load, test, if no problems, put the error at 3/4, otherwise at 1/4, repeat...), or manually evaluate your .emacs line by line (region by region), testing after each portion. Those settings should help.
For me too it did not work. I found with C-h+v that actually max-specpdl-size was not changed to 5 at all by the setq. I then tried to set it interactively with M-x set-variable. That too did not change its value. Finally I managed to set it with M-x customize-variable.
Btw, on my system max-specpdl-size was 140 and thus to small. I had to increase it to 1000, not in order to get a backtrace and debug it, but to make it work.
The kind of bug still exists 10 years after the report, in XEmacs 21.4 (patch 24) "Standard C" [Lucid] (x86_64-linux-gnu, Mule). I get it from M-x vm (trying to read my e-mail, which I do many times every day).
Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
signal(error ("Variable binding depth exceeds max-specpdl-size"))
byte-code("..." [buf data kill-buffer signal] 3)
find-file-noselect("/home/brech/mail/folders/INBOX")
byte-code("..." [f full-startup access-method remote-spec buffer-file-coding-system folder string-match imap pop bufferp nil vm-pop-find-spec-for-name error "No such POP folder: %s" vm-pop-make-filename-for-spec t file-exists-p (rename-file f-pass f-nospec) ((error)) (rename-file f-nopass f-nospec) ((error)) 3 vm-imap-parse-spec-to-list vm-imap-make-filename-for-spec expand-file-name file-directory-p "%s is a directory" vm-get-file-buffer no-conversion raw-text message "Reading %s..." find-file-noselect "Reading %s... done" (pop imap) buffer-name rename-buffer set-buffer-multibyte get-coding-system no-conversion-unix no-conversion-dos no-conversion-mac binary buffer-modified-p ((set-buffer-modified-p omodified)) encode-coding-region set-buffer-file-coding-system decode-coding-region coding-system-base raw-text-unix ...] 9)
ad-Orig-vm(nil nil nil)
(setq ad-return-value (ad-Orig-vm folder read-only access-method))
(let (ad-return-value) (if (and ... mail-archive-file-name folder ... ...) (setq read-only ...)) (setq ad-return-value (ad-Orig-vm folder read-only access-method)) ad-return-value)
(lambda (&optional folder read-only access-method) "$ad-doc: vm$" (interactive (list nil current-prefix-arg)) (let (ad-return-value) (if ... ...) (setq ad-return-value ...) ad-return-value))(nil nil)
call-interactively(vm)
command-execute(vm t)
execute-extended-command(nil)
call-interactively(execute-extended-command)
A crude work-around is quitting XEmacs and starting all over. Only quitting and re-starting vm does not help.
Related
I use Emacs to code. At the moment, to compile an OCaml project, I need to type make in a terminal. If there is an error, I have to go back to Emacs to find the erroneous file and location by following the error indication.
Now, I would like to launch make inside Emacs by a keyboard shortcut, which opens a buffer to show the compilation, then
1) if there is no error, then close the buffer automatically
2) if there is an error, another shortcut will lead me to the erroneous file and line within Emacs.
Does anyone know how to write .emacs to enable this mechanism?
PS: This is my current .emacs.
I have posted a question to compile one .tex file within Emacs by a shortcut (Ctrl + c + m + m), this works well. But in case of error, I don't ask it to lead me to the error position.
M-x compile RET
See the Emacs manual, node Compilation.
And see node Compilation Mode for how to visit error occurrences.
Some years back, I had the same question, here's the answer I got on the #emacs irc channel.
;; from enberg on #emacs
(setq compilation-finish-function
(lambda (buf str)
(if (null (string-match ".*exited abnormally.*" str))
;;no errors, make the compilation window go away in a few seconds
(progn
(run-at-time
"2 sec" nil 'delete-windows-on
(get-buffer-create "*compilation*"))
(message "No Compilation Errors!")))))
;; save the file when I press compile
(setq mode-compile-always-save-buffer-p t)
if this is a duplicate please delete.
I was just editing my .emacs file and after i had my changes done. I
restarted emacs. But whet it comes up again it claims that the config
file has some errors. And i should start with "--debug-init" thats what
i also have done. But it did not helped me to solve nor find the syntax error.
So is there a way to find the lines which have syntaxerror. Or even better if
there would be something like a (e)lisp lint like you have for e.g xml, json, js
and so on. Thanks in advance
Edit
Managed to get the dump:
Debugger entered--Lisp error: (void-variable whitespace-mode)
redisplay_internal\ \(C\ function\)()
delete-process(#<process server-client-test>)
Someunicodefoo" [("server") server-use-tcp server-auth-dir server-socket-dir generate-new-buffer " *temp*" funcall make-byte-code 0 "Someunicodefoo" vconcat vector [buffer-name kill-buffer] 2 "\n\n(fn)" insert-file-contents-literally expand-file-name looking-at "127\\.0\\.0\\.1:[0-9]+ \\([0-9]+\\)" comm process-attributes string-to-number match-string 1 t :other delete-process make-network-process :name "server-client-test" :family local :server nil :noquery :service] 14 "\n\n(fn)"])
server-running-p("server")
byte-code("Someunicodefoo" [load-file-name buffer-file-name recentf-menu-before user-emacs-directory recentf-save-file server-name add-to-list load-path file-name-directory "../packages" tool-bar-mode 0 load "ergoemacs-keybindings/ergoemacs-mode" ergoemacs-mode 1 "init_load_packages" "init_version" "init_functions" "init_settings" "init_aliases" "init_abbrevs-lisp-mode" "init_keybinding" "init_mouse" "init_clean_menus" require recentf "Close" ".recentf" recentf-mode server server-running-p t server-start] 4)
load("/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/../ergoemacs/init")
eval-buffer(#<buffer *load*-842275> nil "/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el" nil t) ; Reading at buffer position 1432
load-with-code-conversion("/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el" "/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el" nil nil)
load("/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el" nil nil t)
load-file("~/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el")
eval-buffer(#<buffer *load*> nil "/home/dirk/.emacs" nil t) ; Reading at buffer position 2883
load-with-code-conversion("/home/dirk/.emacs" "/home/dirk/.emacs" t t)
load("~/.emacs" t t)
command-line()
normal-top-level()
One way to do it is to open the file and mark the first half of it and apply eval-region. If an error is reported, mark half of it and repeat. If an error isn't reported, apply it to the other half.
This way you could narrow down the problem and once you have found it you can hopefully figure out the problem.
Another technique I use to find incorrect parentheses is to add an extra parenthesis to the beginning and end of the file, respectively and run C-M-f and C-M-b from the beginning and end, respectively. If there are incorrect parentheses, they will match the newly added ones, and the point will move to the incorrect ones.
EDIT: You can use M-x check-parens to check for unmatched parentheses.
For "lint"-like checking, there's elint.el, but more importantly, there's the byte-compiler: M-x byte-compile-file RET lets you byte-compile a file and will give you all kinds of warnings about syntax and style.
But your backtrace indicates that the problem is probably not one of syntax. Most like there's a whitespace-mode that appears somewhere in a menu (i.e. in an :enable property of a menu entry), and that signals an error because the whitespace-mode variable happens not to be defined yet. So as Phils suggests, loading whitespace would probably work around the problem.
I'm trying to set up Emacs on my computer and have all backups in a temporary folder, with the following in my .emacs file:
(setq backup-directory-alist
`((".*" . ,temporary-file-directory)))
(setq auto-save-file-name-transforms
`((".*" ,temporary-file-directory t)))
However, I keep on getting the error:
Wrong type argument: stringp, (\, temporary-file-directory)
Which I think is an artefact of the \ / differences between Windows and Unix.
How do I go about stopping this?
Are you sure that you are using a backquote and not a quote? My guess would be that you have
(setq backup-directory-alist '((".*" . ,temporary-file-directory)))
instead of
(setq backup-directory-alist `((".*" . ,temporary-file-directory)))
I think you need to show more about the error context -- where it is raised etc. There is nothing wrong with the backquote sexp you show, AFAICT. And no relation, I expect, with differences between MS Windows and Unix. The question is how the resulting new values for those variables are used. IOW, check (a) whether the new values are what you intended, and if so (b) why they do not seem to be what the code that uses them expects.
Start by setting debug-on-error to t, to see where the error is raised and why. Load the *.el code for that file (defining the function where the error is raised) to improve the debugger backtrace.
But the complaint seems to come from the backquote-processing itself. What happens when you evaluate one of those setq sexps on its own, e.g. using M-: or buffer *scratch*? Do you get the error then? If not, what is the resulting new value of the variable?
Another thing to try, if you get the error even outside your .emacs, is to wrap your setq sexp in (macroexpand ...) and see what the result is.
I am looking for a way to have the Emacs compilation buffer triggered by M-x compile, M-x recompile or some compile on save script only appear when the compilation exits either with an error or a warning.
Note that I am not looking for a way to close the compile buffer if there are no errors or warnings as described in [1]. No I want the buffer to never appear until the compilation is fully finished and only appear if there is an error or warning to display.
The reasons are simple: The flickering compile buffer is disturbing and rearranges the position of the code on the screen. This becomes more annoying if you have compile on save turned on.
The compile buffer contains many different types of compile processes from make to pdflatex so it would be great if the function which determines whether the buffer should be displayed works across the board.
[1] emacs compile buffer auto close?
Looks like you can achieve what you want through temporarily disabling display-buffer across compilation-start.
This is a combination of what sds said and something posted on the comments # here
The comment there had a nasty problem with point jumping in the original source buffer that I appear to have worked out by also blocking set-window-point and goto-char. It feels like a dirty hack, but is working so far. YMMV!
(defun brian-compile-finish (buffer outstr)
(unless (string-match "finished" outstr)
(switch-to-buffer-other-window buffer))
t)
(setq compilation-finish-functions 'brian-compile-finish)
(require 'cl)
(defadvice compilation-start
(around inhibit-display
(command &optional mode name-function highlight-regexp))
(if (not (string-match "^\\(find\\|grep\\)" command))
(flet ((display-buffer)
(set-window-point)
(goto-char))
(fset 'display-buffer 'ignore)
(fset 'goto-char 'ignore)
(fset 'set-window-point 'ignore)
(save-window-excursion
ad-do-it))
ad-do-it))
(ad-activate 'compilation-start)
Now you should see that all compile buffers will only be shown if outstr doesn't return a successful finish status OR the invoked command started with "find" or "grep."
I edited #assem's answer to use cl-letf instead of flet.
(defun brian-compile-finish (buffer outstr)
(unless (string-match "finished" outstr)
(switch-to-buffer-other-window buffer))
t)
(setq compilation-finish-functions 'brian-compile-finish)
(defadvice compilation-start
(around inhibit-display
(command &optional mode name-function highlight-regexp))
(if (not (string-match "^\\(find\\|grep\\)" command))
(cl-letf ((display-buffer #'ignore)
(set-window-point #'ignoreco)
(goto-char #'ignore))
(save-window-excursion
ad-do-it))
ad-do-it))
(ad-activate 'compilation-start)
(provide 'only-display-compile-on-error)
The function compilation-start calls display-buffer on the compilation buffer. This should give you all the control you need.
I.e., you need to customize one of the action variables (display-buffer-overriding-action et al) so that it will handle compilation buffers specially buy displaying it in a separate frame and not displaying the frame itself.
Then you need to customize your compilation-filter-hook so that, whenever a warning or an error is inserted into the compilation buffer, the compilation buffer is displayed visibly (e.g., by popping up the aforementioned separate frame). Don't forget to bind your action variable to nil there!
assems answer has been overtaken by events, somewhat.
Emacs core, in their wisdom have decided to deprecate flet.
The suggested alternative is cl-flet. However, as discussed in this post, this seems to be lexically scoped rather than dynamically scoped. We explicitly want dynamic scoping.
Should `flet` be replaced with `cl-flet` or `cl-letf` ?
This page suggests replace flet to noflet, a third-party library.
This appears to only support the definition of functions and their bodies.
So the flet in assem's answer becomes
(noflet ((display-buffer ()) ....
I recently started using django-html-mumamo-mode which is part of nXhtml in emacs and everything seems to work except that when I start writing javascript code in an html page, I get the warning/error
Can't find library /usr/share/emacs/23.2/lisp/progmodes/js.el
I checked in that folder and all of the files have the .elc extension including js.elc, which is probably why emacs can't find it. Can I change something to make emacs just load the .elc file?
Edit: This continues to occur if I run M-x load-library js or M-x load-library js.elc
Edit2: I have confirmed that load-suffixes is set to ("el" "elc"), and that js.elc is in the progmodes folder, which is in load-path and that all users have read permissions for that file. I am using emacs version 23.2.1, and when I set debug-on-error to t I got a traceback, and it looks like the following part contains the error:
error("Can't find library %s" "/usr/share/emacs/23.2/lisp/progmodes/js.el")
find-library-name("/usr/share/emacs/23.2/lisp/progmodes/js.el")
find-function-search-for-symbol(js-indent-line nil "/usr/share/emacs/23.2/lisp/progmodes/js.elc")
(let* ((lib ...) (where ...) (buf ...) (pos ...)) (with-current-buffer buf (let ... ... ... ...)) (put fun (quote mumamo-evaled) t))
(if (get fun (quote mumamo-evaled)) nil (let* (... ... ... ...) (with-current-buffer buf ...) (put fun ... t)))
(unless (get fun (quote mumamo-evaled)) (let* (... ... ... ...) (with-current-buffer buf ...) (put fun ... t)))
(progn (unless (get fun ...) (let* ... ... ...)))
(if mumamo-stop-widen (progn (unless ... ...)))
(when mumamo-stop-widen (unless (get fun ...) (let* ... ... ...)))
Notably, the third line contains a reference to the correct file, but it ends up trying to load the wrong one. Has anyone seen this kind of thing before or have any idea how to fix it?
If you read the section in the Emacs manual on "How Programs Do Loading, the js.elc file should be loaded if normal library -loading commands (e.g. - "require", "autoload", "load-file", etc) are being used. Some things to do to debug this:
Does your userid have system security permissions to access the js.el file in that location?
If you type M-x emacs-version, what version of Emacs are you running?
The "load-library" command searches for lisp files in the "load-path". When you examine the contents of your load-path, is the specified directory in it?
Set the variable "debug-on-error" to "t" and re-attempt to write javascript code in an html page - when the error occurs, check the source line where the error occurs and, if it's not apparent from that what is causing the problem, post an update to your question with a few lines of the source where the error occurred as well as the stack trace that was produced by Emacs.
EDIT: Ok, now that you've added the stack trace, it's possible to see why the error is occurring. Here are the key lines from the "find-function-search-for-symbol" function (which is the function where the error is occurring in):
(when (string-match "\\.el\\(c\\)\\'" library)
(setq library (substring library 0 (match-beginning 1))))
;; Strip extension from .emacs.el to make sure symbol is searched in
;; .emacs too.
(when (string-match "\\.emacs\\(.el\\)" library)
(setq library (substring library 0 (match-beginning 1))))
(let* ((filename (find-library-name library))
In line#2, the function is setting the library name equal to the "*.elc" library name minus the "c" (e.g. it's converting it from "/usr/share/emacs/23.2/lisp/progmodes/js.elc" to "/usr/share/emacs/23.2/lisp/progmodes/js.el". Then, in line#7 of the above code, it's trying to find that source member (and failing as it doesn't exist). Looking further at the stack trace, the key line is:
(if (get fun (quote mumamo-evaled)) nil (let* (... ... ... ...) (with-current-buffer buf ...) (put fun ... t)))
which is called in the nXhtml "mumamo-funcall-evaled" function. The author of nXhtml obviously has not considered that the ".elc" file may exist but that the ".el" is not in the same directory. It appears that he used to distribute js.el with nXhtml but stopped doing so since it is now shipped with most recent Emacs distributions. So, in his environment, he probably has the ".el" files in the same directory as the ".elc" files and hasn't encountered this problem.So, you should probably do 2 things:
Notify the author of the nXhtml library so that he can fix the bug in his code.
Copy the necessary ".el" source files to "/usr/share/emacs/23.2/lisp/progmodes/" so that you don't get the error. Alternatively, you may choose to re-install js.el (and possibly some other modules) in another directory and put that directory ahead of "/usr/share/emacs/23.2/lisp/progmodes/" in your "load-path".
Doing #1 will get the problem fixed in the long-term while doing #2 should let you use nXhtml in the short-term.
Check your value of load-suffixes
C-h v load-suffixes. You probably want this to be something like (".elc" ".el"). If it is make sure that your mode hasn't set it to something weird, or bound it dynamically.