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.
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).
We use an internal scripting language (let's call it pkc), which allows for embedding C++ code. The C++ code segments are delimited by {{{ and }}} markers.
I create an emacs mode for this language, using Generic Mode and mmm-mode.
Here is what I got (stripped down non-essential parts for posting here):
(require 'generic-x)
(setq pkc-imenu-generic-expression
'(("macros" "^[ \t]*macro[ \n\t]+\\([a-zA-Z0-9_]+\\)" 1)
("functions" "function[ \n\t]+\\([a-zA-Z0-9_]+\\)" 1)
))
(require 'cc-mode) ;; for c++-mode
(require 'mmm-auto)
(setq mmm-global-mode 'maybe)
(define-generic-mode
'pkc-mode ;; name of the mode to create
'("//" ("/*" . "*/")) ;; comments are same C++ comments
'( ... ) ;; some keywords
'("\\.pkc$") ;; files for which to activate this mode
;; other functions to call
'((lambda ()
(mmm-mode 1)
(setq mmm-submode-decoration-level 2)
(setq imenu-generic-expression pkc-imenu-generic-expression)
(which-function-mode 1)
(c-initialize-cc-mode t)
(c-init-language-vars-for 'c++-mode)
(c-common-init 'c++-mode)
(c-update-modeline)
(message "pkc-mode[mmm] is on")))
"A mode for pkc source files" ;; doc string for this mode
)
(mmm-add-classes
'((embedded-c++
:submode c++-mode
:face mmm-default-submode-face
:front "{{{"
:front-offset -1
:back "}}}"
:back-offset 1)))
(mmm-add-mode-ext-class 'pkc-mode nil 'embedded-c++)
When I load the source file with embedded C++ code segments, they are highlighted somewhat less than what would have been if C++ mode was the major mode (that's not my problem, however). When the cursor in C++ code, the modeline changes to pkc/l[C++/l] (as expected).
The problem is, whenever I press TAB to indent a line, I get the error Wrong type argument: stringp, nil. When I turned on debugger, this is the stack trace I see:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
c-syntactic-skip-backward(nil nil t)
c-looking-at-decl-block(nil t)
c-guess-basic-syntax()
c-indent-line()
#[nil \302>\203)\212\303 \210\304\305x\210\303 \210\306 )i\306 X\203\"\307 !\202'\212\307 !))\20 \207" [indent-line-function column (indent-relative indent-relative-maybe) beginning-of-line "\n " nil current-indentation indent-line-to] 2 1908700 nil]()
c-indent-command(nil)
c-indent-line-or-region(nil nil)
call-interactively(c-indent-line-or-region nil nil)
Looking at the definition of c-looking-at-decl-block and particularly the call to `c-syntactic-skip-backward, I find:
(c-syntactic-skip-backward c-block-prefix-charset limit t)
Examining the first argument c-block-prefix-charset reveals that its value is nil. Doing the same from a plain C++ buffer shows a non-nil value. So, I suspect that C++-mode requires some initialization that's not being properly done.
So, my questions are:
What am I missing in the C++-mode initialization section in my implementation?
Am I using the right approach (combining generic-x and mmm-mode)? Is there a better approach?
I also see another error (File mode specification error) when I load the file, but I suspect the problem is the same or something similar.
Thanks for your time.
(Rewritten after the discussion in the comments, for any later visitors).
The setup in the question is basically fine, but to work with current c++-mode you need to use an updated version of mmm-mode. It's available at the GitHub project page and also at Melpa.
The relevant patches (one, two, three) added new entries to the value of mmm-save-local-variables, which mmm-mode uses to decide which local variables to save or restore when leaving or entering a submode region.
From what I understand, a future update to cc-mode can add more such vars, so the list may need to be updated from time to time.
Extra tip: to have better indentation in the subregions, you may want to wrap the submode's indent-line-function with some code that will narrow the buffer before calling it (example here). Depending on the indentation function (and whether it calls widen), it may or may not help.
I'm using GNU Emacs 23.3 on Windows. I work in a very large codebase for which I generate a TAGS file (using the etags binary supplied with Emacs). The TAGS file is quite large (usually hovers around 100MB). I rarely need to use any functionality beyond find-tag, but there are times when I wish I could do completion out of the TAGS table.
Calling complete-tag causes Emacs to make a completion table automatically. The process takes quite a bit of time, but my problem isn't in the amount of time it takes, but rather the fact that right at the end (around 100% completion), I get a stack overflow (sorry about the unprintable chars):
Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
re-search-forward("^\\(\\([^]+[^-a-zA-Z0-9_+*$:]+\\)?\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:]*\\)\\(\\([^\n]+\\)\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n" nil t)
etags-tags-completion-table()
byte-code(...)
tags-completion-table()
Has anyone else run into this? Know of a way to work around it?
EDIT: Stack output after turning on debug-on-error
EDIT: Removed stack, since I now know what the failing entries look like:
^L
c:\path\to\some\header.h,0
^L
c:\path\to\some\otherheader.h,0
My tags file contains quite a few entries in this format. Looking at the headers involved, it's clear that they couldn't be correctly parsed by etags. This is fine, but I'm surprised that tags-completion-table doesn't account for this format in its regex. For reference, here's what a real entry looks like:
^L
c:\path\to\some\validheader.h,115
class CSomeClass ^?12,345
bool SomeMethod(^?CSomeClass::SomeMethod^A67,890
The regexp in question is used to match a tag entry inside the TAGS file. I guess that the error can occur if the file is incorrectly formatted (e.g. using non-native line-endings), or if an entry simply is really, really large. (An entry is typically a line or two, which should not be a problem for the regexp matcher.)
One way of tracking down the problem is go to the TAGS buffer and see where the point (cursor) is, after the error has occurred. Once you know which function it is, and you could live without tags for it, you could simply avoid generating TAGS entries for it.
If the problem is due to too complex entry, I would suggest that you should send bug report to the Emacs team.
If you load the tags table (open the TAGS table with Emacs, then bury-buffer), try M-x dabbrev-expand (bound to M-/). If the present prefix is very common, you might end up running through many possible completions before reaching the desired one.
I don't use Windows, but on the Mac and Linux machines I use, I have not faced this issue.
This looks like a bug in Emacs, see:
https://groups.google.com/d/msg/gnu.emacs.help/Ew0sTxk0C-g/YsTPVEKTBAAJ
https://debbugs.gnu.org/db/20/20703.html
I have applied the suggested patch to etags-tags-completion-table (copied below in completeness for your convenience) and trapped an error case.
I'm triggering the error in an extremely long line of code (46,000 characters!). I presume somebody programmatically generated the line and pasted it into the source. A workaround could be to simply filter such lines at the ctag building or loading stage, just something that deletes "long" lines, whatever that may mean. Probably 500 characters is long enough!
I could also look at adding maximum sizes to my regexes in ctags, but that really isn't a general solution because many ctags patterns do not have such limits.
(defun etags-tags-completion-table () ; Doc string?
(let ((table (make-vector 511 0))
(progress-reporter
(make-progress-reporter
(format "Making tags completion table for %s..." buffer-file-name)
(point-min) (point-max))))
(save-excursion
(goto-char (point-min))
;; This monster regexp matches an etags tag line.
;; \1 is the string to match;
;; \2 is not interesting;
;; \3 is the guessed tag name; XXX guess should be better eg DEFUN
;; \4 is not interesting;
;; \5 is the explicitly-specified tag name.
;; \6 is the line to start searching at;
;; \7 is the char to start searching at.
(condition-case err
(while (re-search-forward
"^\\(\\([^\177]+[^-a-zA-Z0-9_+*$:\177]+\\)?\
\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:\177]*\\)\177\
\\(\\([^\n\001]+\\)\001\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n"
nil t)
(intern (prog1 (if (match-beginning 5)
;; There is an explicit tag name.
(buffer-substring (match-beginning 5) (match-end 5))
;; No explicit tag name. Best guess.
(buffer-substring (match-beginning 3) (match-end 3)))
(progress-reporter-update progress-reporter (point)))
table))
(error
(message "error happened near %d" (point))
(error (error-message-string err)))))
table))
I'm trying to set some keybindings to use the Shift key to highlight text. I could use pc-selection-mode, but that doesn't offer all the key bindings I want. For example, I'd like to be able to shift-mark an entire paragraph by pressing Shift-Ctrl-down which I can do in most MS text editors, but pc-selection-mode doesn't allow you to do this.
I found this website which has a shift_mark.el file I can use to set all the key bindings I want. I've put in my .xemacs/init.el file to load shift_mark.el.
This is the error:
Warning (initialization): An error occurred while loading `/home/theory/phrkaj/\
.xemacs/init.el':
Wrong type argument: arrayp, (shift right)
So I've run Emacs with --debug-init to try and find the problem. This is what the debugger came up with:
Debugger entered--Lisp error: (wrong-type-argument arrayp (shift right))
signal(wrong-type-argument (arrayp (shift right)))
global-set-key((shift right) shift-mark-forward-char)
eval-buffer(#<buffer *load*<3>> nil "/home/theory/phrkaj/shift_mark.el" nil t) ; Reading at buffer position 1476
load-with-code-conversion("/home/theory/phrkaj/shift_mark.el" "/home/theory/phrkaj/shift_mark.el" nil nil)
load("~/shift_mark.el")
eval-buffer(#<buffer *load*<2>> nil "/home/theory/phrkaj/.xemacs/init.el" nil t) ; Reading at buffer position 25
load-with-code-conversion("/home/theory/phrkaj/.xemacs/init.el" "/home/theory/phrkaj/.xemacs/init.el" nil nil)
load("/home/theory/phrkaj/.xemacs/init.el" nil nil t)
load-file("/home/theory/phrkaj/.xemacs/init.el")
eval-buffer(#<buffer *load*> nil "/home/theory/phrkaj/.emacs" nil t) ; Reading at buffer position 253
load-with-code-conversion("/home/theory/phrkaj/.emacs" "/home/theory/phrkaj/.emacs" t t)
load("~/.emacs" t t)
#[nil "^H\205\264^# \306=\203^Q^#\307^H\310Q\2027^# \311=\2033^#\312\307\313\314#\203#^#\315\2027^#\312\307\313\316#\203/^#\317\2027^#\315\2027^#\307^H\320Q^Z\321^S\322\n\321\211#\210^K\321=\203_^#\323\324\325\307^H\326Q!\"^\\322\f\$
command-line()
normal-top-level()
Here's part of the shift_mark.el file which defines the highlighting of one char forward:
(defun shift-mark-forward-char ()
(interactive)
(shift-mark 'forward-char))
(global-set-key '(shift right) 'shift-mark-forward-char)
Any help is appreciated.
Under GNU Emacs, the key binding should look like
(global-set-key [(shift right)] 'shift-mark-forward-char)
([…] constructs a literal array). But I suspect you're going at this the wrong way. Are you running GNU Emacs, XEmacs, or both? What versions? Unless you're running extremely old versions, pc-selection-mode should do what you want under GNU Emacs, and no setup should be required under XEmacs. If you run both GNU Emacs and XEmacs, you can use the following code in your .emacs:
(defvar running-xemacs (string-match "XEmacs" emacs-version))
(if (not running-xemacs)
(pc-selection-mode 1))
C-hv shift-select-mode RET
shift-select-mode is a variable defined in `simple.el'.
Its value is nil
Documentation:
When non-nil, shifted motion keys activate the mark momentarily.
While the mark is activated in this way, any shift-translated point
motion key extends the region, and if Transient Mark mode was off, it
is temporarily turned on. Furthermore, the mark will be deactivated
by any subsequent point motion key that was not shift-translated, or
by any action that normally deactivates the mark in Transient Mark mode.
See `this-command-keys-shift-translated' for the meaning of
shift-translation.
You can customize this variable.
This variable was introduced in GNU Emacs 23.1:
** Temporarily active regions
* The new variable shift-select-mode, non-nil by default, controls
shift-selection. When Shift Select mode is on, shift-translated
motion keys (e.g. S-left and S-down) activate and extend a temporary
region, similar to mouse-selection.
* Temporarily active regions, created using shift-selection or
mouse-selection, are not necessarily deactivated in the next command.
They are only deactivated after point motion commands that are not
shift-translated, or after commands that would ordinarily deactivate
the mark in Transient Mark mode (e.g., any command that modifies the
buffer).
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.