# Emacs Plus: Homebrew Formulae and Casks for a GUI Emacs on macOS

> Emacs Plus ships Cocoa Emacs.app builds for macOS through Homebrew, either as a pre-built cask or compiled from source with extra patches. The plus is mostly macOS defaults and a YAML customization layer, not a different editor.

**d12frosted/homebrew-emacs-plus** — Emacs Plus formulae for the Homebrew package manager

- Repository: https://github.com/d12frosted/homebrew-emacs-plus
- Stars: 2,937 · Forks: 218
- Language: Ruby
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/d12frosted-homebrew-emacs-plus

## What Emacs Plus adds over the core Homebrew emacs formula

The core Homebrew emacs formula is configured with --without-ns, so it produces a terminal-only Emacs and no Emacs.app. Emacs Plus builds a full Cocoa application instead, and adds a companion Emacs Client.app that opens files from Finder through emacsclient and handles org-protocol:// links. That is the difference most people notice first, because it decides whether Emacs can be your default GUI editor on macOS.

The README lists the rest of the plus: native compilation is on by default, PATH is captured from your shell at install time and injected into Emacs.app so binaries installed by package managers work in GUI Emacs without exec-path-from-shell, and a small set of patches is applied by default. The most notable patch is ns-system-appearance-change-functions, a hook that fires when macOS switches between light and dark appearance.

The project is explicit that this list used to be longer. Many patches that were exclusive to Emacs Plus were merged into Emacs itself, and the core formula improved too. The README's own summary is that the plus is now mostly sane macOS defaults plus the customization layer on top. Read that as a maturity statement, not a marketing one: if you are choosing Emacs Plus for a single exotic patch, check whether that patch still lives here or has landed upstream.

## Stable, next and master: how the three lanes map to casks and formulae

Emacs Plus is organized as three lanes, and each lane exists twice: once as a cask that installs a pre-built binary, and once as a formula that compiles from source. The stable lane maps to the emacs-plus-app cask and the emacs-plus formula, both tracking the latest release, which the README gives as 31.1. The next lane corresponds to emacs-plus-app@next and emacs-plus@master. The master lane corresponds to emacs-plus-app@master and emacs-plus@master.

That naming is the first thing to get right, because the cask and formula names differ for the same lane. emacs-plus-app@next is a nightly from the release branch; emacs-plus-app@master is a nightly from master. On the formula side, brew install emacs-plus --HEAD builds from the release branch, while emacs-plus@master builds from master. The README also notes old versions down to Emacs 26, and the Makefile exposes formula-29, formula-30, formula-31 and formula-32 targets for local development builds.

The release cadence visible in the repository is high: cask-stable-341 was published on 2026-09-21, cask-next-340 on 2026-09-21, and cask-master-342 on 2026-09-22. The last push to the repository was on 2026-09-22. If you pin to a nightly lane, expect that moving target; if you want a build you can reproduce months later, the stable lane is the one to pick.

## Installing Emacs Plus and running a first GUI session

Homebrew 6.0 and later does not load non-official taps until you trust them, and brew tap checks every formula and cask before accepting a tap, so the trust step comes first. The README gives this example:

```bash
brew trust d12frosted/emacs-plus
brew tap d12frosted/emacs-plus
```

After that, choose a lane. The cask path installs a self-contained Emacs.app from a pre-built binary and, per the README, takes about a minute with no compilation involved:

```bash
brew install --cask emacs-plus-app
```

The formula path builds from source, which the README estimates at about 30 minutes, and is the path to take when you want options or a custom build:

```bash
brew install emacs-plus
```

Once installed, Emacs.app lives in your Applications folder as a normal macOS application, and the companion Emacs Client.app can open files from Finder through emacsclient. To confirm which build you are running, the README documents a detection mechanism covered in the next section. If you later want to test local changes to the repository itself rather than a released build, the Makefile provides make cask, make cask@next and make cask@master targets, and make validate to check a build.yml configuration.

## Build Configuration: one YAML file for icons, patches and community extras

The customization layer is a single file, ~/.config/emacs-plus/build.yml. The README says you can pick one of more than 70 icons, apply community patches, or point to any external or local patch and icon, including ones the repository knows nothing about. That last clause matters: the build system will fetch and apply patches from outside this project, so the trust boundary of your Emacs build extends beyond the tap you trusted.

The Makefile includes a validate target, described as validating build.yml for both formula and cask, which gives you a way to check the file before a long compile rather than discovering a typo 20 minutes in. The repository layout supports the same story: there are patches/, community/, iconset and Library/ directories at the top level, alongside Casks/ and Formula/.

The trade-off is that a YAML-driven build is convenient but not self-documenting. Nothing in the README excerpt describes a rollback path for a build.yml that produces a broken Emacs, and no lockfile or checksum for externally referenced patches is mentioned. If your build.yml points at a patch on a branch someone else controls, your reproducibility depends on that branch.

## Detecting Emacs Plus and the macOS-specific behaviour it injects

The README documents a detection mechanism, which matters if your Emacs configuration needs to branch on whether it is running under Emacs Plus rather than the core formula or another macOS build. That is a real need: the injected PATH and the appearance hook are Emacs Plus behaviours, and code that assumes them will misbehave elsewhere.

The injected PATH is the feature with the widest blast radius. Emacs Plus captures PATH from your shell at install time and bakes it into Emacs.app. The benefit is that GUI Emacs finds binaries installed by package managers without exec-path-from-shell. The cost is that the PATH is a snapshot: it reflects the shell environment at install time, not at launch time. If you install a new toolchain afterwards, or change your shell configuration, the GUI application will not necessarily see it until the build is refreshed. That is a design choice, and it is the kind of thing that produces bug reports which look like Emacs problems but are packaging problems.

The other macOS-specific behaviour is the ns-system-appearance-change-functions hook, which fires when the system switches between light and dark appearance. For anyone who wants theme switching to follow the system, this avoids a polling workaround. The README does not describe how the hook behaves for frames created after an appearance change, so verify that against your own configuration.

## Where Emacs Plus is the wrong choice

The clearest case against Emacs Plus is that you do not need it. If you work in a terminal, the core emacs formula already gives you Emacs, and the Cocoa application, the injected PATH and the appearance hook are all irrelevant. Installing a 30-minute source build to get features you will not use is wasted effort.

The second case is reproducibility-sensitive environments. The formula lane compiles from source, and the README's own estimate is about 30 minutes; the nightly lanes track branches that move. On a machine fleet, that means either a long install per machine or a build you have to cache yourself. The cask lane sidesteps the compile time, but you are then consuming pre-built binaries from the tap, which is a different trust decision than compiling from source you can read.

The third case concerns the build.yml customization layer. Because it can reference external or local patches and icons that this repository knows nothing about, a heavily customized build is only as trustworthy as the sources you point at. If your policy is that every line compiled into your editor must be reviewed, Emacs Plus makes that harder than a plain build from the upstream Emacs tarball, not easier. The README does not claim otherwise; it simply documents the capability.

## How Emacs Plus differs from emacs-mac and from building Emacs yourself

The related searches people use around this project include emacs-plus vs emacs-mac, so the comparison is worth stating precisely. emacs-mac is the other well-known macOS-oriented Emacs distribution, and the difference in approach is where the patches come from. Emacs Plus is a Homebrew tap: formulae and casks that build or install Emacs.app, with its own patch set and a YAML file for icons and community patches. The README frames the project's history as patches migrating upstream into Emacs over time, which means the distinguishing set is smaller now than it once was.

Against building Emacs yourself from a tarball or a Git checkout, Emacs Plus is packaging. You get Homebrew dependency resolution, a cask that installs in about a minute, and a formula that applies the project's defaults so you do not have to remember --with-ns and the native compilation setup. What you give up is control over the exact configure flags and the patch order, unless you go through build.yml, and you take on the tap as a dependency.

Against the core Homebrew emacs formula, the difference is narrower and better defined: Emacs.app, native compilation by default, injected PATH, default patches, more versions, and pre-built binaries. Those are the six items the README lists, and they are the honest basis for the choice.

## Conclusion

Adopt Emacs Plus if you run Emacs on macOS and want a Cocoa Emacs.app with native compilation and an injected PATH without maintaining your own build. Skip it if you only use terminal Emacs, or if you want a build whose patches you have audited line by line; the README points at community patches and external sources. Before installing, run brew trust d12frosted/emacs-plus, then decide between the emacs-plus-app cask and the emacs-plus formula, because that choice determines whether you wait about a minute or about 30 minutes.

## FAQ

### How do I install Emacs Plus with Homebrew?

Trust the tap first with brew trust d12frosted/emacs-plus, then run brew tap d12frosted/emacs-plus. From there, brew install --cask emacs-plus-app installs a pre-built binary in about a minute, while brew install emacs-plus builds from source in roughly 30 minutes.

### What is the best Emacs version for Mac?

The README does not rank versions, but it describes three lanes: stable (latest release, given as 31.1), nightlies from the release branch, and nightlies from master, plus old versions down to Emacs 26. The stable lane is the one to pick if you want a build you can reproduce later.

### Why was Emacs removed from macOS?

The README does not address this. It describes Emacs Plus as formulae for the Homebrew package manager and compares it to the core Homebrew emacs formula, which it says is built with --without-ns and therefore has no Emacs.app.

## Sources

- [d12frosted/homebrew-emacs-plus on GitHub](https://github.com/d12frosted/homebrew-emacs-plus)
- [Issues](https://github.com/d12frosted/homebrew-emacs-plus/issues)
- [License: MIT](https://github.com/d12frosted/homebrew-emacs-plus/blob/master/LICENSE)
- [README](https://github.com/d12frosted/homebrew-emacs-plus/blob/master/README.md)
- [Releases](https://github.com/d12frosted/homebrew-emacs-plus/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/d12frosted-homebrew-emacs-plus