# minimal-emacs.d: two files that replace a whole Emacs framework > minimal-emacs.d is an Emacs starter kit made of exactly two files, an init.el and an early-init.el, totalling roughly 450 lines once comments are stripped. It sets better defaults and tunes startup without loading any package or forcing any mode, which is the trade it offers against Doom and Spacemacs. **jamescherti/minimal-emacs.d** — minimal-emacs.d - Emacs init.el and early-init.el for Better Defaults and Optimized Startup, intended to serve as a solid foundation for your vanilla Emacs configuration | Emacs Starter Kit - Repository: https://github.com/jamescherti/minimal-emacs.d - Website: https://github.com/jamescherti/minimal-emacs.d - Stars: 929 · Forks: 118 - Language: Emacs Lisp - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/jamescherti-minimal-emacs-d ## Two files, no framework, no package requirement minimal-emacs.d is an Emacs init.el and early-init.el intended to serve as a foundation for a vanilla Emacs configuration. The repository top level contains exactly what the name promises: ```text early-init.el init.el ``` alongside README.md, a .github directory with a CI workflow, a .gitignore and a .LICENSE file. The design constraint is stated without hedging: the project loads zero packages and imposes no modes. Unlike other frameworks, the README says, minimal-emacs.d does not impose modes or require packages, and you keep full control over which global or minor modes to enable. That is the whole proposition, and it is a real one. Emacs ships with a large amount of well-designed behaviour, but it also keeps settings that reflect historical constraints or legacy compatibility, as the README puts it, and the work of a starter kit is to replace the latter without discarding the former. minimal-emacs.d positions itself as designed to be extended rather than replaced, and the README offers extensive recommendations for customising it. The size is the other headline. Excluding empty lines, comments and docstrings, the configuration is approximately 450 lines long, and the README is explicit that it does not introduce additional functionality beyond offering improved default settings. Two files you can read in an evening is a fundamentally different proposition from a package system you adopt on trust. ## early-init.el versus init.el, and why the split exists The two files divide along the Emacs startup timeline, and understanding that division is what makes the project useful rather than a pile of preferences. early-init.el is loaded early in the startup process, before the graphical interface is initialized. The README notes that this file was introduced in Emacs 27, and that it configures settings which influence startup performance and GUI behaviour prior to package loading. This is the file that matters most for speed, because anything set here is in place before Emacs starts pulling in package code. init.el is loaded after the graphical interface is initialized and contains the user customisations: variable settings, package loading, mode configurations and keybindings. It is the file you edit day to day. The distinction is not academic. Emacs reads init.el only after the GUI exists, so anything in init.el that affects startup competes with the interface for time, whereas the same setting placed in early-init.el is applied during the cheap phase. A starter kit that understands this split can spend its budget where the milliseconds are. For the user, the practical consequence is that you can adopt one file without the other. Someone who wants faster startup but has an existing init.el can take early-init.el alone, which is a much smaller change to review than replacing both. ## Better defaults and garbage collection tuning The README states the criterion it used to choose every setting: does it provide a better default that modernizes Emacs while keeping it lightweight, fast and stable? And it says the result was the outcome of extensive research and testing to fine-tune the best parameters and optimizations for an Emacs configuration. Two areas are named explicitly in the feature description: improved settings for usability and UI, and garbage collection. The garbage collection point comes up repeatedly in the project community material, including a testimonial from a user who says the configuration eliminates the need to sift through conflicting advice on garbage collection optimization. Garbage collection in Emacs is a classic example of a setting where the built-in default and the advice online disagree. Emacs runs a garbage collector on a timer, and its behaviour interacts with how long a session runs and how much memory is in use. Tuning it is a common early step for people who notice input lag, and a well-known source of contradictory advice. A starter kit that has made a decision and documented the reasoning is more useful than one that leaves the default in place. The README also mentions built-in packages among the areas it adjusts, which is a reminder that minimal here means minimal in the package sense. Emacs ships with a substantial set of built-in functionality, and changing how that is configured is different from adding third-party code. ## The startup figure and the conditions attached to it The README publishes a specific number: the author uses minimal-emacs.d as his early-init.el and init.el alongside 146 packages, and yet Emacs still starts in just 0.22 seconds. That figure comes with the caveat the README states immediately after it. Startup speed depends on hardware and disk speed, and for consistent comparisons you should test on the same computer and Emacs version. The README also notes that while startup time is significant, factors like native compilation are also important for long-term performance. The caveat is the honest part, and it should be read carefully. A 0.22 second startup on the author's machine with 146 packages is a claim about one configuration on one computer, not a general property. Native compilation is the other lever mentioned, and it is the one that changes how fast the Lisp itself runs once loaded, rather than how long the load takes. There is a second reason to be careful with the number. It comes from the author's own setup, and the packages that make it impressive are the author's choices, listed on his site rather than bundled here. Someone reproducing the measurement with a different package set, on different hardware, will get a different number, and the difference will not be attributable to the two files. ## Licensing that needs reading before you copy the files The README badge states GPL v3, and the README's own metadata section lists the license as GPL. The licence field on the repository, however, reports an unknown licence that GitHub cannot classify, and the file at the root of the tree is named .LICENSE rather than LICENSE. Those three statements are close enough to be consistent and awkward enough to be worth checking. The .LICENSE filename is unusual, and it is the kind of naming that some automated licence scanners skip, which would explain why GitHub reports nothing while the badge claims GPL v3. For a configuration file that you copy into your own Emacs setup, the GPL matters in a specific way. The GPL v3 applies to the work itself, and if you distribute a configuration that is derived from this one, the copyleft terms travel with it. That is different from the licence of a package you install from MELPA, where the package carries its own terms and your configuration is your own. The practical guidance is not legal advice but common sense: read .LICENSE before you publish a configuration derived from these files, and keep the attribution. The project also asks, in the README, that people who find it useful consider starring it on GitHub and sharing it on their website, blog, Mastodon, Reddit, X, LinkedIn or other platforms. That is a request about visibility, not a measure of the configuration's quality. ## Where this sits against Doom and Spacemacs The README names its comparison points directly. It says you bypass hours of configuration and the heavy overhead of frameworks like Doom or Spacemacs, gaining optimized garbage collection, sensible defaults and a fast startup. The real difference is not the number of features, it is where the decisions live. A framework such as Doom or Spacemacs is a package with its own configuration language, its own module system and its own opinion about keybindings, modes and which packages you should have. You adopt it and you then work inside it, extending it in its own idiom. minimal-emacs.d ships two Lisp files that you read, that you can copy into your own configuration, and that you can edit line by line. That has a clear upside and a clear cost. The upside is that there is no layer between you and Emacs, no package system to learn, and nothing loaded that you did not ask for. The cost is that the pleasant defaults of a mature framework, the working LSP setup, the project management commands and the batteries-included keybinding scheme, are all work you either do yourself or skip. The repository is therefore best understood as a teaching artefact as much as a starting point. One of the community comments in the README calls it a great learning resource, and another says it helps people who already have established ways of organising their configs, which is a good sign for a project whose goal is to be readable rather than to be complete. For maintenance, the repository is not archived and the last push was on 2026-10-14, with no GitHub releases, so the configuration is tracked by commits rather than by tags. A CI workflow runs on the repository, which for a pair of Lisp files most likely checks that they still load. ## Conclusion minimal-emacs.d suits an Emacs user who wants a well tuned starting point without handing control of the configuration to a framework, and who is comfortable reading about 450 lines of Lisp to understand what has been changed on their machine. It does not suit someone who wants a working set of packages, an opinionated mode map and keybinding scheme out of the box, because the project loads nothing and forces nothing. Before adopting, read both files before copying them into your own Emacs configuration, check the licence situation in the .LICENSE file at the root of the repository, and measure your own startup time on the same machine and Emacs version before and after, since the published figure depends on hardware and disk speed. ## FAQ ### What is minimal-emacs.d and what does it contain? It is a minimal Emacs starter kit made of two files, an early-init.el loaded before the GUI is initialized and an init.el loaded after it. Excluding empty lines, comments and docstrings the configuration is approximately 450 lines long. ### Does minimal-emacs.d install any Emacs packages? No. The README states that it loads zero packages and imposes no modes, and that you keep full control over which global or minor modes to enable. It adjusts settings and defaults rather than adding third-party code. ### What is the difference between early-init.el and init.el? early-init.el is loaded early in startup, before the graphical interface is initialized, and configures settings that influence startup performance and GUI behaviour. It was introduced in Emacs 27. init.el is loaded after the GUI exists and holds variable settings, package loading, mode configurations and keybindings. ### How fast does Emacs start with minimal-emacs.d? The README reports that the author starts Emacs in just 0.22 seconds while using 146 packages with the configuration. It also states that startup speed depends on hardware and disk speed, that comparisons should be made on the same computer and Emacs version, and that native compilation matters for long-term performance. ### What licence does minimal-emacs.d use? The README badge and metadata state GPL v3, while the repository is classified as having an unknown licence and the root file is named .LICENSE. Read that file before redistributing a configuration derived from these two files. ## Sources - [Issues](https://github.com/jamescherti/minimal-emacs.d/issues) - [jamescherti/minimal-emacs.d on GitHub](https://github.com/jamescherti/minimal-emacs.d) - [Project website](https://github.com/jamescherti/minimal-emacs.d) - [README](https://github.com/jamescherti/minimal-emacs.d/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jamescherti-minimal-emacs-d