My emacs is somehow getting misconfigured, so that SPC in non-C modes is trying to do C-mode stuff. If I set debug-on-error to true and press space in a shell buffer, I get this backtrace.
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
looking-at(nil)
c-state-semi-safe-place(465791)
c-literal-limits(nil nil)
c-mask-paragraph(nil t do-auto-fill)
c-do-auto-fill()
self-insert-command(1)
call-interactively(self-insert-command nil nil)
command-execute(self-insert-command)
I do not have a good way to reproduce it, but it happens fairly consistently when I load my (large, complicated) .emacs and work for a few hours.
It is entirely possible that I set something wrong in my .emacs, or it could be one of the packages I've recently added. I can probably figure out the problem if I know where to look. However, debug-when-behavior-of-space-command-is-changed does not seem to be a built-in option.
What are good options for figuring out what is changing the behavior of self-insert-command?
I am using:
GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)
of 2015-04-10 on builder10-9.porkrind.org
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)
I'm an evil Emacs user. However, I really only use the normal mode for fancy Vim style edits when I find them more convenient than regular Emacs commands. (Mostly fancy bulk editing/yanking/deleting). However, I'm also a huge user of the minibuffer (I do a lot of M-x with ido and flx so I can avoid remembering the more esoteric commands). When I do, evil switches to normal mode automatically after I exit. I find that very annoying/confusing. How can I get it to stop? (preferably in an elegant, non-hackish way).
Thanks,
PythonNut
EDIT:
It appears that the switch to normal mode happens in all windows and in all frames.
I cannot reproduce your issue; maybe knowing your versions could help anyone to identify your issue. Can you reproduce your issue with "emacs -q" (plus adding evil to load-path)?
Here is an approach to identify the evil (traditional English meaning) piece of code, if any, that is calling to evil-normal-state:
(defadvice evil-normal-state (before debug-issue activate)
(setq debug-on-error t)
(inexisting-function-will-fail))
Eval this just after setting a buffer in the evil-state you want it to be, then go to to the minibuffer with M-x. Is there an stacktrace?
You may reactivate evil-mode by adding whatever function you use to activate it to minibuffer-exit-hook.
I am trying to get started with RefTeX in Emacs 24.1.50.3, built --without-x. Running
(reftex-citation)
seems to work at first. I can enter a regex and get a list of matching citations in my bibliography. However, selecting an entry makes the buffer stops working. Attempting to navigate gives the following error
Debugger entered--Lisp error: (error "Marker does not point anywhere")
posn-at-point()
line-move-visual(1 nil)
line-move(1 nil nil 1)
byte-code("\302\303\211 $\207" [arg try-vscroll line-move nil] 5)
next-line(1 1)
call-interactively(next-line nil nil)
This should not be caused by my init.el, because it occurs even when I launch emacs with --no-site-files and enter (reftex-mode) manually.
Actually, --no-site-file does not inhibit your init.el file.
See C-hig (emacs) Initial Options RET
Start emacs -Q to be sure this is not being caused by non-standard libraries.
If so, then it sounds like a bug, in which case:
M-x report-emacs-bug RET
Some times when I mess up with icicles, dired, sunrise commander or some other guy -
number-or-marker-p
error pops up - and it nearly blocks emacs - no query-find-replace works, no ido any more. The only way - is to restart emacs. Does any body have a way to make emacs forget this error?
What should it do instead of issuing an error? Let's say you try M-x query-find-replace and this error happens. Should the operation just silently do nothing? At least with the error you know that something has gone wrong.
Either stop what you're doing that is breaking things, or fix (get it fixed) the underlying problem.
To start the process of fixing the bug, try setting debug-on-error to t, triggering the error and looking at the stack trace. Or add this to your .emacs:
(setq debug-on-error t)
Update the question with the backtrace and start again...