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 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 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.

  • Start Emacs with emacs -Q and do the same thing. Does this produce an error?
    – nitishch
    Commented Nov 2, 2015 at 17:28
  • 1
    If I start Emacs with emacs -Q, then there is no "Apply and save" option available to make the change permanent.
    – davesailer
    Commented Nov 3, 2015 at 22:58
  • Are your customize settings part of your init file or are they in a separate file? Commented Nov 4, 2015 at 12:42
  • Everything is in init.el except what I have customized via the menu system that does not show up there.
    – davesailer
    Commented Nov 5, 2015 at 21:31

4 Answers 4


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.

  • Thanks. That's a completely logical answer, but I can't make use of it. The init.el file is the only one I have access to, and there have been no recent changes to it, so I can't see that it is the source of any problems. I haven't directly modified any other file. If it's some system file, but I have no idea where it could be or what I could possibly do about it even if I knew. I completely reinstalled Emacs yesterday, but that was no help either. I do appreciate your answer. My apologies, but this looks more and more like a lost cause, short of wiping the hard drive and starting over.
    – davesailer
    Commented Nov 4, 2015 at 14:25
  • @davesailer It's possible the recent change was inadvertent. Before getting to a harddrive wipe, try looking at char 30586 in your init.el file, it shouldn't take long and will at least rule out the init.el file being corrupt. Commented Nov 4, 2015 at 16:12
  • Character 30586 is the letter "e" in key in (global-set-key [?\C-c ?h] [? ?& ?m ?d ?a ?s ?h ?; ? ]) There are 153 "(" and 153 ")" beginning with "(global-set-key..." I haven't touched anything around there in years. This whole exercise is probably pointless by now. I'll just have to live with it and trust that it'll get sorted out by the next time I upgrade Linux, in a year or two.
    – davesailer
    Commented Nov 5, 2015 at 21:32
  • 1
    @davesailer That line is the problem. The ";" is the start of a comment and so the close paren is invisible. I get the same error from that line.
    – erikstokes
    Commented Nov 6, 2015 at 2:46
  • @davesailer I still don't understand how that line being there could have not caused any problem earlier.. unless you had that whole line commented out, until recently when it got uncommented due to some reason. Commented Nov 6, 2015 at 3:38

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.

  • 1
    I haven't tired but it think this would work and would look cleaner: (global-set-key (kbd "C-c h") "—"). I'll verify that when I'm at a computer. Or even better, use abbrev. Commented Nov 7, 2015 at 14:12
  • Update: that global-set-key works as I expected. But also have a look at abbrev. Commented Nov 7, 2015 at 17:52
  • Yep. Very nice. I feel smarter already, which means that I'll be able to start making more sophisticated dumb mistakes. Can't wait to use it. Thank you for this little gift.
    – davesailer
    Commented Nov 9, 2015 at 12:20

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).


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.

  • You can also try using C-M-f from the beginning and see when you reach an sexp that does not complete. Commented Nov 4, 2015 at 12:45
  • @JonathanLeech-Pepin: Good addition.
    – Drew
    Commented Nov 4, 2015 at 14:32
  • Well that IS a nifty command. C-M-f stops at the end of (global-set-key [?\C-c ?l] [home ?\C-s ?a ?r ?f ?f return]). That line from the current init.el is identical to the line from my .emacs file, versioned 2009-03-16A. The previous and succeeding lines are also identical in the two files. I probably deserve this. I'll just have to live with it until a miracle happens. My next project is figuring how to log out of this place. Still haven't figured that out either, and I'm not all dumb. (Your opinion may differ.)
    – davesailer
    Commented Nov 5, 2015 at 21:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.