I want to debug some problems with my elisp files.

But emacs --debug-init is not revealing anything more than if I simply run emacs wint the command emacs.

The command emacs gives a warnings window with the text

Warning (initialization): An error occurred while loading ‘/home/ephram/.emacs’:

End of file during parsing: /home/ephram/typex.el

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace.

It would help to have some more details when one uses emacs --debug-init but I get the same as in the command emacs.

  • All --debug-init does is drop you into the debugger if it encounters an error while running your init file. If you’re not seeing the debugger, then there must not have been an error. Congratulations! Levity aside, try being more explicit about what you see and what you expected to see. A screenshot, for example, would go a long way.
    – db48x
    Jun 16, 2022 at 2:38
  • What's the question? I don't see a question.
    – Drew
    Jun 16, 2022 at 3:46

3 Answers 3


A parse error while loading a Lisp file seems to prevent the debugger from firing.

If you wonder why typex.el is loaded

Add the following line at the top of typex.el:


Then start Emacs normally. When it tries to load typex.el, you'll see a backtrace of the call to load that file.

If you want to find the error inside typex.el

The debugger won't help you with that. A debugger helps you figure out what some code is doing when it runs. If the code doesn't even get to the point of being able to run, there's nothing for a debugger to do.

Emacs doesn't always give good feedback on a parse error. (Presumably not a lot of work has gone into it because Lisp is simple and parse errors are uncommon.) For “End of file during parsing”, do the parsing yourself and find out where the problem is. Start from the beginning of the file and repeat the command forward-sexp until it errors out. To do that, make a macro that calls this command, and use kmacro-end-or-call-macro or kmacro-end-and-call-macro with the argument 0 to repeat the macro until an error occurs

f3 C-M-f ESC 0 f4

The point stops where the last, unfinished sexp of the file starts.

  • This is a much more sensible reply than You just have to learn how to use it well. given by some.
    – Dilna
    Jun 16, 2022 at 20:26
  • @Ephram: I agree that this is a good answer, but the "less sensible" answer to which that particular comment was added also included (from the outset) the same solution which is presented here (which I'll note is also what my suggestion of check-parens will achieve).
    – phils
    Jun 17, 2022 at 0:32

You're not getting a run-time debugger because Emacs didn't get as far as running the code -- the error in question is End of file during parsing so it couldn't successfully read that file in the first place.

You'll need to visit the indicated file and fix the problems.

M-x check-parens may be a good start.

  • Emacs didn't get as far as running the code in the problematic file, but it did get as far as calling load (or require or equivalent) on that file. It's reasonable to expect the debugger to show a backtrace of that call. Jun 16, 2022 at 18:14

(What's the question?)

Emacs told you that your file typex.el is syntactically incorrect - it reached the end of file (e.g., missing right parentheses) while trying to parse/read it. As it said:

investigate and remove the cause of the error in your initialization file.

So bisect typex.el to find the culprit. You can easily and quickly bisect it by commenting out 1/2, then 3/4, 7/8, 15/16,... of it. You can comment out a block of text by selecting it and using M-x comment-region. You can uncomment a selection by using C-u M-x comment-region.

Or select 1/2, then 3/4,... of the code at a time and use M-x eval-region.

A check with 1/2, 3/4,... is a binary search - it's very fast. And it's systematic - you can't miss anything. And it requires little thought.

Another possibility is to start at the beginning of the file and use C-M-f, to move past each sexp in turn, till you find one that isn't terminated properly (e.g. missing right parens). (But that's not a binary search.)

Personally, instead of comment-region I use this, from misc-cmds.el, binding it to C-x C-;:

(defun comment-region-lines (beg end &optional arg)
  "Like `comment-region' (which see), but comment or uncomment whole lines."
  (interactive "*r\nP")
  (when (> beg end) (setq beg  (prog1 end (setq end  beg))))
  (let ((bol  (save-excursion (goto-char beg) (line-beginning-position)))
        (eol  (save-excursion (goto-char end) (if (bolp)
    (comment-region bol eol arg)))

  • I was hoping that emacs would provide additional hints with --debug-init then without. But I get the same text in the *Warnings* buffer.
    – Dilna
    Jun 16, 2022 at 4:30
  • C-u M-x comment-region is the archaic way of doing things. It works but involves a lot of effort to comment hundreds of lines. Expected some tools would have been written to help debugging by this time.
    – Dilna
    Jun 16, 2022 at 4:34
  • No. There's nothing archaic about it. You just have to learn how to use it well. You could have easily found your error already, in no time at all.
    – Drew
    Jun 16, 2022 at 14:48
  • Archaic, because if it was gcc, it would give you an indication of what the problem might be rather than just say An error occurred while loading.
    – Dilna
    Jun 16, 2022 at 20:24
  • 1
    The An error occurred while loading … line is generic, you get that no matter what the error was. The next line has the specific error that you got: End of file during parsing: …. Could this be a better message? Sure. It’s not quite “archaic”, but it is from about 30 years ago when compilers had simpler error messages. If you want to be helpful, go to lread.c and look at the seven different places that call end_of_file_error and design better error messages for each of them.
    – db48x
    Jun 17, 2022 at 5:48

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.