forward-sexp: Scan error: "Unbalanced parentheses", 30586, 41369

Question

When using the menu system to modify customizations (Options > Customize Emacs > ...etc...), I am

• Able to "Apply" the change for the curent session

• Unable to "Apply and save" for future sessions

The error message I get is 'forward-sexp: Scan error: "Unbalanced parentheses", 30586, 41369'.

I have no idea how to deal with this message. Online searches produce random results, none of which relate to my problem.

I am exploring and learning about org-mode. About three days ago I was able to make a change related to customizing a default option for org-mode without a problem.

Then a few minutes later when I tried to add another custom setting, I got the above "forward-sexp..." error and continue to. I get this error when attempting to "Apply and save" any setting whatsoever, such as changing the color of the default face.

I tried swapping in an old "init.el" file, firing up a new emacs session, and making a change, but "Apply and save" also fails under those circumstances, so the problem does not appear related to my "init.el" file being corrupt.

Beyond that, I'm clueless.

Update 2015-11-03

Thank you Drew for your long and thoughtful reply. I'm still out to sea though.

I put (setq debug-on-error t) at the top of my init.el file and attempted to change the color of the default face, uisng the Cutsomize option from the emacs menu.

I had to try three times before I got any backtrace output. Unfortunately, to me it's meaningless, but here it is...

Debugger entered--Lisp error: (scan-error "Unbalanced parentheses" 30598 41177) scan-sexps(1 41176) forward-sexp(41176)
custom-save-delete(custom-set-variables) custom-save-variables()
custom-save-all() Custom-save((push-button :tag " Apply and Save " :help-echo "Apply settings and save for future sessions." :action Custom-save :button-overlay # :from # :to #) (mouse-1 (# 191 (270 . 121) 23286452 nil 191 (26 . 5) nil (0 . 12) (10 . 25))))
widget-apply((push-button :tag " Apply and Save " :help-echo "Apply settings and save for future sessions." :action Custom-save :button-overlay # :from # :to #) :action (mouse-1 (# 191 (270 . 121) 23286452 nil 191 (26 . 5) nil (0 . 12) (10 . 25))))
widget-apply-action((push-button :tag " Apply and Save " :help-echo "Apply settings and save for future sessions." :action Custom-save :button-overlay # :from # :to #) (mouse-1 (# 191 (270 . 121) 23286452 nil 191 (26 . 5) nil (0 . 12) (10 . 25)))) #[0 "\306 r\307\310\311\312\313\314!\315\"\316\317%DC\216\320\321\300@!\211,@)!\210\212\321\300@!,\322,8\206B`

Then I used diff to compare the resulting modified but unsaved init.el, and an init.el from last May.

There were two differences,

• (setq debug-on-error t) on line one of today's init.el. and
• a macro that I edited about three weeks ago

Since I was able to do one customization a couple of days ago with no problem, and unable since then, the macro editing is not an issue

The main part of the custom-set-variables secton of the init file hasn't been changed for years.

It is...

(custom-set-variables
  ;; custom-set-variables was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
 '(auto-save-interval 75)
 '(auto-save-timeout 10)
 '(blink-cursor-mode nil)
 '(bookmark-save-flag 0)
 '(column-number-mode t)
 '(dired-listing-switches "-al --group-directories-first --time-style=long-iso")
 '(display-time-day-and-date t)
 '(display-time-mode t)
 '(fill-column 110)
 '(fringe-mode 2 nil (fringe))
 '(inhibit-startup-screen t)
 '(ispell-highlight-face (quote highlight))
 '(ispell-highlight-p t)
 '(ispell-program-name "aspell" t)
 '(load-home-init-file t t)
 '(ls-lisp-dirs-first t)
 '(make-backup-files nil)
 '(scroll-bar-mode (quote right))
 '(sentence-end-double-space nil)
 '(sort-fold-case t t)
 '(tool-bar-mode nil)
 '(truncate-lines t)
 '(vc-make-backup-files t)
 '(version-control t)
 '(visible-bell t)
 '(x-select-enable-clipboard t))
;;(custom-set-faces
  ;; custom-set-faces was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
;; )

The other part has been set for many months, and is...

;; make pandoc the default markdown parser (custom-set-variables '(markdown-command "/usr/bin/pandoc"))

Earlier today I reinstalled all the Emacs packages as well, but no change from that either.

Update 2015-11-06: Edited. Reply reconfigured and moved into a whole new answer for clarity.

Answer 1

Based on some quick testing of forward-sexp, the numbers listed in the error message define where the unbounded sexp are found.

Adding a bare ( to my init file then trying forward-sexp I received: forward-sexp: Scan error: "Unbalanced parentheses", 436, 52245.

M-: (point) on the ( gave 436 and M-: (point-max) gave 52245.

In your case: M-g c (goto-char) 30586 should send you to the ( that the file cannot find an end to.

Answer 2

First, there was a suggestion to write my own answer rather than editing the question. Also, thanks to everyone for supplying intelligent and thoughtful comments. I obviously needed the help.

---

I had a saved keyboard macro set to produce —, which is an em dash for use in HTML.

The macro looked like (global-set-key [?\C-c ?h] [? ?& ?m ?d ?a ?s ?h ?; ? ]).

Me? Clueless, so I just ended the expression with a semicolon and a space. And oddly enough, it works fine. It did work fine, until I did a bit of customizing via the Emacs menu system while adding a couple of tweaks to make use of some Org mode features.

Now that I understand where the problem is and why it should be a problem it all (finally) makes sense. The semicolon begins a comment, which causes two parenthetical expressions to be not-closed, i.e. ] and ). This actually is reasonable in the Emacs world. Even I can understand it.

But it gets better.

The init.el file, bent as it was, still let itself be saved without even a tiny squeak of protest, and ran perfectly. It was only when I tried something like changing the face color, for example, that init.el would get ornery. And reluctantly throw a an error message. I guess we have to call it a message even though I've had better communications with a drunken chicken. (Her name was Heather, by the way. She was actually pretty astute at times, besides the eggs too, but then there was that drinking problem. Anyhow.)

So there I was, up to my elbows in a bucket of snakes all going every whichway and suddenly it all made sense, at which point I knew I'd better start backing away or it would soon be too late.

Emacs. Make sense? Ow.

So after about six hours more searching, I found \ (It's how you draw an escape hatch in Emacs). So I added that to the macro and it kept working. And now whenever I get in there and try to do some customizing and things get hot and furious, that little escape hatch pops open and lets out enough steam so things don't blow up any more.

The updated macro with the escape hatch now looks like:

(global-set-key [?\C-c ?h] [? ?& ?m ?d ?a ?s ?h ?\; ? ]).

I guess the moral of the story is that you can stick your head into a fan if you want, or stick it into Emacs. Pretty much the same result, except that Emacs can also do —.

If it really has to.

Answer 3

I also had this issue and I couldn't find any error or unbalanced parentheses in my own configuration (I'm using Spacemacs and have a .spacemacs file). I tried with a clean .spacemacs file and the same problem remained (even the two numbers shown in the error are the same).

This led me to conclude that some file must have been messed up in my .emacs.d folder. Deleting that folder completely and re-cloning Spacemacs solved the issue (while preserving the original .spacemacs file and my configurations of course).

Answer 4

Put this in your init file, near the beginning:

(setq debug-on-error  t)

Post the backtrace you see when you get the error.

---

You mention using Customize, as if that is related to your problem. But you don't say just what you did in Customize. If, for example, you customized an option that expects a Lisp value, and you entered a sexp that is missing one or more right parentheses or a string terminator (") or some such, then that could explain the error you are seeing.

---

You can try to find what is provoking the problem in your init file by recursively bisecting it, to narrow it down. Use comment-region to comment out a selection of sexps (or C-u with that command to uncomment a selection). Comment out 1/2, then 3/4, 7/8,... of your init file.

If you are convinced that the problem is something you changed using Customize, then you can try just commenting out parts of the custom-set-variables part of your init file - each of its parts is a sexp that customizes one option. Comment out 1/2 of them, then 3/4,... until you find the one that is problematic. Then check that one for a missing termination (paren or " or ])

---

But without more information all we can say is that Emacs is trying to evaluate a sexp that is unfinished -- missing something that should end it.