I am using emacs version 24.4.2. For some reason, i cannot use tramp at all. Any attempt to do so, i.e. trying to type /sudo:: causes a small hang of application followed by the following error in messages buffer:
expand-file-name: Lisp nesting exceeds `max-lisp-eval-depth'
What can i do to fix that error or diagnose it properly?
Update: Debugging shows the source of a problem is ido. Currently it is set up with following:
(setq ido-everywhere t)
(ido-mode t)
(setq ido-enable-flex-matching t)
Set debug-on-error to non-nil. See what function called expand-file-name, producing the error. Then try M-x debug-on-entry F, where F is that function, and step through the debugger with d to see what happens. Look at the code defining that function, in another window, while using the debugger.
You can also try, first, seeing whether you get the same broken behavior when you start Emacs without your init file: emacs -Q. If not, then recursively bisect your init file to find out what part of it introduces the problem.
My crystal ball is whispering to me that you have advised a function in such a way that it ends up, directly or indirectly, calling itself.
Related
Every time I try to create or visit a file with a ".txt" extension, I get a stack trace like the following:
Debugger entered--Lisp error: (wrong-number-of-arguments quote 0)
quote()
set-auto-mode-0(quote nil)
set-auto-mode()
normal-mode(t)
after-find-file(nil t)
find-file-noselect-1(#<buffer file.txt> "~/path/to/file.txt" nil nil "~/path/to/file.txt" (24122033 2049))
find-file-noselect("/home/me/path/to/file.txt" nil nil)
ido-file-internal(raise-frame)
ido-find-file()
call-interactively(ido-find-file nil nil)
The buffer "file.txt" is open, however, in fundamental mode. This happens whether I use ido_find-file or M-x find file.
I tried to fix this by adding the following line in my init.el file:
(add-to-list 'auto-mode-alist '("\\.txt$" . text-mode))
...and I've changed the txt to [tT][xX][tT], switched out a \\' for the $, and tried fundamental-mode instead of text-mode; but no combination of changes seems to make the error go away.
I'm working with GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2), on xubuntu linux.
I presume the error starts with set-auto-mode(), but I don't know that for sure, and I don't know why the parens would be empty there. Has anyone else had this problem, or know what I'm doing wrong here?
If it's an auto-mode-alist issue, evaluate the following to confirm which mode Emacs is getting from that:
(assoc-default "foo.txt" auto-mode-alist 'string-match)
If it's nil, that's certainly the problem, and you do have a problem with your auto-mode-alist configuration.
It's probably not that, though -- there are a bunch of other things Emacs tries in set-auto-mode, so you likely need to narrow it down.
Try this:
M-x find-library RET files RET
M-x eval-buffer RET
C-xC-f foo.txt RET
Having evaluated the functions (n.b. you could really just evaluate set-auto-mode), you should now get a far more detailed stack trace when you hit the debugger, so you'll be able to figure out exactly where in set-auto-mode the call to set-auto-mode-0 is happening, and consequently which mechanism is resulting in a nil value for the major mode symbol.
(If you're unsure how to proceed from there, paste the stack trace into the question.)
I suspect that the problem is coming from a faultly local variables declaration in your file /home/me/path/to/file.txt. Do you have a local variables declaration in that file, and does it perhaps contain a quote (') that should not be there?
But I agree with the good advice that #phils gave, for tracking this down. There are a few different ways in which set-auto-mode can try to determine the mode. You will need to find out which one was being used (unless perhaps my guess helps).
I'm facing a very bizarre behaviour. No matter how I set ac-auto-start, be it through customization, by evaluating (setq ac-auto-start 2), (setq-default ac-auto-start 2) or (setq-local ac-auto-start 2) immediately after I do it, the variable is set to nil.
I've looked through the source of auto-complete mode and the ac-slime in my case, but none of these does nothing to this variable. I am at a loss as to how to deal with this.
The effective consequences of this malfunction is that completion combobox doesn't appear on its own, unless I force it to by doing M-x auto-complete. This behaviour is consistent in all modes where auto-complete minor mode is enabled.
EDIT
This seems to be an issue with latest Emacs. Now it fails to modify variables values, no matter what variable it is. So, say, after running it with -Q I've now discovered that I can't evaluate the code that uses (setq ...) forms as it has no effect. :/ So, please, hold on, I'll try to investigate this...
This was due to the typo, but the original problem is still there.
Emacs version is 24.3.50.1 pulled from trunk about a week ago.
auto-complete is version 1.4 installed from MELPA.
I'm setting the variable by moving the point to the REPL buffer, then M-:. I check its value in the same way.
EDIT2
OK, I finally found the reason: I had enzyme package installed, and it had an earlier version of auto-complete inside of it, for some reason parts of the auto-complete code were loaded from there and other parts from the one installed from MELPA. After disabling enzyme it all works well now.
EDIT3
This still happens after I run (auto-complete-mode 1) in the REPL buffer. The variable will become impossible to set. I've searched through various autocomplete timers that may be setting something, but no luck so far.
There is indeed something strange going on with the setting of auto-complete-mode.
(I'm using the ELPA version in a GNU Emacs 24.3.1)
This is set up by customize-group RET auto-complete :
'(ac-auto-show-menu t)
'(ac-auto-start t)
At this point if you M-x auto-complete-mode you get a [no match] right in the minibuffer. Only after you try to M-x auto-complete, yelding a "auto-complete-mode is not enabled" weird error, will you be able to M-x auto-complete-mode (but without command completion... Hm) and then be in the mode.
If you put this in your init file (.emacs)
(require 'auto-complete)
(auto-complete-mode t)
It will be effective only if you re-eval it after startup (?!?).
The same with something like
(if (auto-complete)
(auto-complete-mode t))
The only way that I found to get auto-complete-mode to load at startup is to :
(eval-and-compile
(require 'auto-complete nil 'noerror))
(The above customize options are now effective)
After adding the following code in my .emacs file, comes up some error during startup of emacs. I am a newbie of emacs, is there some one can help me figure out where are the errors come from?
Added code in .emacs:
;; Auto-saving the Desktop
(require 'desktop)
(desktop-save-mode 1)
(defun my-desktop-save ()
(interactive)
;; Don't call desktop-save-in-desktop-dir, as it prints a message.
(if (eq (desktop-owner) (emacs-pid))
(desktop-save desktop-dirname)))
(add-hook 'auto-save-hook 'my-desktop-save)
Errors:
Looking at the function definition for what's breaking, it seems that the error is that prj-file is NIL in line 492. (The other expand-filename call in the function shouldn't ever have a nil, since it's the car of a non-nil list of filenames).
Now, prj-file is the first filename in /home/shenyan/Test/memcached-1.4.11 matching the regexp "\\(Root\\)?ProjStep.ede" and presumably there isn't one. Since memcached presumably doesn't have an EDE project file, what's gone wrong must be that line 508's call to ede-project-p did something weird when called with this subdirectory of /home/shenyan/Test/.
I can't work out exactly why that happened, but you can debug things quite easily. First bring up your *scratch* buffer to type emacs lisp easily. To check my guess, insert the following code into the buffer
(ede-directory-project-p "/home/shenyan/Test/memcached-1.4.11")
and run it by hitting C-x C-e with cursor on the closing bracket. If it returns nil I was wrong. Otherwise, you've found the culprit and should probably debug it further by hunting through the bits of ede-directory-project-p in ede-files.el.
Probably what's going on is that your /home/shenyan/Test/ directory has something that tells EDE to search subdirectories (or maybe that's the default?) and then the memcached subdirectory has a file whose name makes EDE think it should be searched for a project file. If you work out exactly what happened, you might consider submitting a bug to the EDE developers: they probably shouldn't error out if the project file doesn't exist.
This is rather queer. I can't set any value to a variable if it is named 's' in an interactive session:
(setq s 'foo)
=> foo
s
=> nil
Why?
Update 1:
Here is the output from describe-variable on s:
s is void as a variable.
Documentation:
Not documented as a variable.
Why is it that s is kept void in emacs lisp as a global variable?
Update 2:
Turned out, it doesn't happen on a vanilla emacs (meaning one of the modules I load in .emacs or some code in .emacs is causing this).
So the question now is:
What would the original source look like when describe-variable yields "<var> is void as a variable"?
I tried it with setq, defconst, defvar, and defcustom, but none of those produced the message I'm showing.
Update 3:
The message shown above is produced when the variable is literally not bound (though it can be fbound).
(describe-variable 'non-existent)
=> "non-existent is void as a variable.
Documentation:
Not documented as a variable."
So latest question is: Is there any way to prevent a certain variable name
from being bound?
An answer to your revised question:
(defvar s)
The only thing is that this won't let you use describe-variable on it interactively.
(You could then do something like (setplist 's '(variable-documentation "Meh")) to set a description for it without going through defvar.
Just bisect your init file (~/.emacs) recursively until you find the sexp that causes the problem. If it is a sexp that loads another library then either don't use that library or fix it by first finding out what its problem is, the same way: bisect the code in that library recursively, etc.
This is a binary search, and it is very quick. You can quickly comment out half, then 3/4, 7/8, etc. of your file, using M-x comment-region (I bind it to C-x ;). with a prefix arg, comment-region uncomments.
With Emacs 23.1, running the following code makes C-h v s RET show “s is void as a variable.”, but I can't reproduce the inconsistency between setq and retrieving the value of the variable (which I agree is weird).
(setq s t)
(make-local-variable 's)
(makunbound 's)
I suspect an Emacs 24-specific feature or bug.
I've been getting this error in emacs whenever I type anything in certain buffers:
c-forward-sws: Wrong type argument: stringp, nil
It seems to be a syntax highlighting thing; I'm getting it in a buffer that's in sh-mode whenever I type anything -- even return on an empty line. I have also occasionally gotten it in a C++-mode buffer but I don't remember the specific line, nor can I reproduce it in such a mode.
I have not changed my .emacs lately (that I can recall).
Any ideas what the problem is? The function is defined in cc-engine.el but I'm having a hard time figuring out the context.
Chances are good that you have auto-fill-mode on and the auto-fill-function is c-do-auto-fill, which doesn't work so well for other languages. Either turn auto fil off (M-x auto-fill-mode) or change the value of the fill function.
You should be able to debug the entry to auto-fill-mode explicitly with M-x debug-on-entry RET auto-fill-mode and see what's invoking it. There's probably a hook that's turning it on, which will appear in the stack trace.
[Update]
I found that the global value of auto-fill-function was being set (it's supposed to always be buffer-local). The result is that all buffers default to using auto fill with that function. I haven't determined how the global value is being set, but it can be cleared up using (setq-default auto-fill-function nil).
To figure out the problem, you need to do a little more investigation. What you've provided isn't enough (unless the answerer has already seen the specific problem).
The first step is generally to set the variable debug-on-error to t. This will provide a stack trace with more information (generally telling you which expression inside the function is causing the problem).
If you can reliably reproduce the problem, then don't set the above variable, but instead go to the function definition (M-x find-function c-forward-sws RET), and set it up for debugging with M-x edebug-defun. Then do what causes the error and step through the code. The debugger is pretty intuitive if you're familiar with looking at lisp, and the documentation can be found on this info page.
At the very least, adding the stack trace might provide enough information to lead to an answer, though likely it'll take a test case to reproduce the problem...