If I am correct, emacs is both an editor and an interpreter (or compiler?) of the elisp language.

Is emacs init.el used for emacs as an editor or as an interpreter of elisp?

  • If we use Emacs as an editor, the its init.el can be seen as the configuration file for this software.

  • If we use Emacs with the --batch option, is it similar to what .bashrc is for bash as an interpreter of bash language? Does the init.el get loaded then?

  • The way "we view Emacs" makes no difference on what files get used. Did you mean to say "If we use Emacs as [...]"? And if you did mean that, what do you mean by "as an interpreter of elisp"? Emacs is always an interpreter of elisp. Are you talking about the --batch option?
    – Malabarba
    Commented Sep 29, 2014 at 9:34
  • @Malabarba: yes, yes.
    – Tim
    Commented Sep 29, 2014 at 13:18

5 Answers 5


To supplement what others have said about Emacs the editor and its relation to Emacs Lisp, Emacs as an editor works this way:

Keys you hit or mouse actions you make are bound to interactive Emacs-Lisp functions called commands.

More precisely, key sequences are bound to commands. A key sequence might be just hitting one keyboard key. Or it might be hitting multiple keys, either together as a chord (using modifier keys such as Control and Shift) or sequentially.

Key sequences that are not bound to commands are either ignored or have a default effect - typically raising an error telling you that that key sequence is not bound.

It is worth repeating that this is pretty much all that Emacs does. Even when you type the letter a by hitting the a key, to insert an a in a text buffer, an Emacs command is invoked: the command named self-insert-command. In a nutshell: Everything you do in Emacs amounts to invoking Lisp functions by hitting keys.

The keyboard keys that you typically think of as entering text (a, K, 9, %, etc.) are generally bound to command self-insert-command in contexts where text insertion makes sense.

In other contexts, the same key might be bound to another command. For example, in the Emacs directory editor (mode Dired), the key a reads a file name and then visits that file. In still other contexts, the same key (e.g. a) might not be bound, and Emacs tells you so when you hit it.

So you can think of Emacs as an interpreter of Emacs Lisp. Or you can think of Emacs as a bunch of bindings of keys to Emacs-Lisp functions - that is, you can think of Emacs as Emacs Lisp with some keyboard "hooks".

  • +1, But you seem to be positing that Emacs is an Emacs Lisp interpreter, which also conveniently allows for text editing. I would argue that Emacs is first and foremost a text editor which happens to use Emacs Lisp as one of its primary means of manipulating strings and scripting high-level behavior. A lot of the Emacs backbone is still built from C code, and performs functions that are critical to Emacs but have nothing to do with interpreting Emacs Lisp. If the elisp "interpreter" were written in C, and the the editor itself was written in elisp, then I would agree with this viewpoint.
    – nispio
    Commented Oct 3, 2014 at 19:06
  • @nispio I disagree. A lot of core Ruby methods are written in C as well, but irb is still considered to be a Ruby interpreter. Many Emacs functions happen to be written in C for performance reasons, but they behave exactly like Lisp functions--they can be redefined, advised, used in a higher-order context, etc.
    – shosti
    Commented Oct 4, 2014 at 4:16
  • 1
    Emacs goes beyond just being an interpreter, and provides a framework that can be leveraged through elisp code. I expect that there are lots of things that Emacs implements in C not because it is faster, but because it cannot be done in elisp alone. I will admit that the line is blurry, because it largely depends on whether you consider some of the objects that Emacs provides (e.g. windows, frames, screen updates) to be part of the elisp language specification. Until you have an unambiguous definition of where the language ends and the libraries begin, the philosophical debate remains. :)
    – nispio
    Commented Oct 4, 2014 at 5:36
  • Yeah, I think Ruby + Rails + Pry (for fancy interaction) is probably a better analogy. I'm not an expert in Emacs internals, but I think "cannot be done in elisp" is a major overstatement--if the GUILE thing goes through, most of the C code will be replaced with Scheme. In general, the non-Elisp portions tend to be focused around system integration and window management--most editing functions other than the most primitive commands are written in Elisp.
    – shosti
    Commented Oct 6, 2014 at 16:17
  • This answer reminded me of this: xkcd.com/722
    – mbork
    Commented Nov 12, 2014 at 18:05

Emacs as editor

~/.emacs.d/init.el and the equivalen ~/.emacs,~/.emacs.el all serve as the source of user-specific customization for emacs. When emacs is launched these are sourced to provide you with your desired editing environment.

Emacs in --batch

--batch implies -q (--no-init-file) according to emacs --help. This means customizations are not included when launching a batch process. You can manually tell it to include your customizations by running emacs --batch -l ~/.emacs.d/init.el.

It does however still include the site-lisp directory (so packages bundled with emacs or installed to site-lisp will still be available/loaded). To ensure they are not added you can run emacs --batch -Q or emacs --batch --no-site-lisp. If you have a specific set of packages you need run when launching a batch process best would be to create a file that requires the specific files (~/.emacs.d/batch.el) and sets any variables as desired then run emacs --batch -l ~/.emacs.d/batch.el --eval <command>.


Emacs is an interpreter with a large number of built-in commands for editing. Typing text calls self-insert-command, which is an interactive function that inserts text in the current buffer.

Emacs is not a compiler, but it does provide bytecode. You can compile a file to bytecode (from foo.el you get a foo.elc file). This bytecode is then interpreted (much like Python or Ruby) and is interpreted a little bit faster than interpreting the .el directly.

init.el is just a script that is run by Emacs as it starts up. You don't have to run it. The bash equivalent is .bashrc, which is just a bash script that's executed on startup. There's no Python equivalent. To start Emacs without running init.el:

$ emacs --no-init-file

You also don't have to start an editor window, you can run Emacs as just a CLI interpreter (this is not useful very often).

$ emacs --batch --eval '(message "hello world")'

Is emacs init.el used for emacs as an editor or as an interpreter of elisp?

The emacs init file contains personal elisp code that you want to execute when you start emacs.

is it similar to what .bashrc is for bash as an interpreter of bash language?

.bashrc contains personal bash code that you want to execute when you start your shell.

does Python also has something such as init.py, for preloading some packages when starting the interpreter?

.pythonrc contains personal python code that you want to execute when you start your python shell


Emacs is an interpreter of Elisp with some interactive features around text editing. That is all. The text editing capabilities are best thought of as an Elisp "program" (with other "programs" being things like GNUS). Thus, your second definition (equivalent of .bashrc) is the correct one--init.el contains actual code that is executed on startup, not "configuration" in the sense of my.conf or similar.


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.