Linux ist die natürliche Heimat von Emacs — und gleichzeitig die Plattform mit der größten Auswahl. Praktisch jede Distribution liefert ein eigenes emacs-Paket im offiziellen Repository, oft jedoch ein bis zwei Major-Versionen hinter dem aktuellen Stable-Release. Daneben gibt es Flatpak und Snap als distro-unabhängige Sandbox-Pakete sowie den Build aus dem Quellcode, der als einziger Weg alle modernen Optionen — Native Compilation, tree-sitter und den pgtk-Wayland-Build — frei kombinieren lässt. Dieser Artikel zeigt alle vier Wege, ordnet sie nach Aufwand und Aktualität ein und installiert auf jeder relevanten Distribution einen lauffähigen Emacs.

Die Wege auf einen Blick

Auf Linux konkurrieren vier Installations-Wege. Sie liefern denselben Editor, unterscheiden sich aber stark in Aktualität, Integration und Aufwand.

VarianteQuelleStärkeWann sinnvoll
Distro-Paketapt, dnf, pacman, zypper, apktiefe System-Integration, ein Befehl, automatische UpdatesStandard-Setup; Arch und Fedora liefern aktuelle Versionen
FlatpakFlathub (org.gnu.emacs)distro-unabhängig, sandboxed, immer aktuellDistros mit veraltetem Paket (Ubuntu LTS, Debian Stable)
SnapSnap Store (emacs)distro-unabhängig (vor allem Ubuntu)Notlösung — Snap-Confinement schränkt vieles ein
Build from Sourcegit.savannah.gnu.org/emacs.gitvolle Kontrolle: native-comp, tree-sitter, pgtk, eigene configure-FlagsPower-User; Maintainer, die mehrere Versionen parallel halten

Die kurze Empfehlung: Arch, Fedora und openSUSE Tumbleweed bringen so aktuelle Pakete mit, dass das Distro-Paket genügt. Auf Ubuntu LTS und Debian Stable lohnt sich Flatpak oder ein eigener Build, weil das Repo-Paket häufig deutlich hinter dem Stable-Release liegt. Wer Wayland-natives Rendering, tree-sitter-Modes mit selbst gewählten Grammars und Native-Compilation in einer Installation kombinieren will, baut aus dem Source.

Variante A — Distro-Paketmanager

Der einfachste Weg ist immer das Paket der eigenen Distribution. Die folgende Übersicht installiert auf jeder relevanten Familie einen GUI-Emacs samt Terminal-Variante.

Debian und Ubuntu

shell Debian/Ubuntu
sudo apt update
sudo apt install emacs

Debian und Ubuntu kennen mehrere Paket-Varianten: emacs (Meta-Paket, zieht GUI-Build), emacs-gtk (explizit GTK-GUI), emacs-pgtk (Wayland-nativer Build, seit Ubuntu 24.04 verfügbar) und emacs-nox (reine Terminal-Variante ohne X-/Wayland-Abhängigkeiten). Server-Setups installieren häufig nur emacs-nox.

shell Variante explizit wählen
# Wayland-nativer Build (empfohlen auf Wayland-Sessions)
sudo apt install emacs-pgtk

# Reine Terminal-Variante (Server, SSH-only)
sudo apt install emacs-nox

Ubuntu LTS-Releases liegen oft ein bis zwei Major-Versionen hinter dem aktuellen Stable. Wer einen neueren Emacs auf einem LTS will, greift entweder zu Flatpak (siehe Abschnitt 03) oder zu einem PPA wie ppa:ubuntuhandbook1/emacs, das aktuelle Builds pflegt.

Fedora und RHEL-Familie

shell Fedora / RHEL / Alma / Rocky
sudo dnf install emacs

Fedora liefert in der Regel den aktuellen Stable-Release. Native-Compilation ist im Default-Paket aktiviert. Für die reine Terminal-Variante:

shell Fedora ohne GUI
sudo dnf install emacs-nox

Arch und Manjaro

shell Arch / Manjaro
# GTK-Build (Default)
sudo pacman -S emacs

# Wayland-nativer pgtk-Build
sudo pacman -S emacs-wayland

# Reine Terminal-Variante
sudo pacman -S emacs-nox

Arch verfolgt den Upstream sehr eng — das extra-Repo enthält fast immer den aktuellen Stable. Für die jeweils brandneuesten Pretest- oder Git-Builds existieren emacs-git und Verwandte im AUR.

openSUSE

shell openSUSE Leap / Tumbleweed
sudo zypper install emacs

Tumbleweed liefert wie Arch nahezu Upstream-aktuelle Pakete, Leap eher konservativ. Für die GTK-Variante separat: emacs-x11 (X11/GTK) bzw. emacs-nox.

Alpine

shell Alpine Linux
# Repository "community" muss aktiviert sein
sudo apk add emacs

# Reine Terminal-Variante (deutlich kleiner)
sudo apk add emacs-nox

Alpine ist auf Servern und in Containern populär — emacs-nox ist dort der gängige Default, weil keine GUI-Bibliotheken mitkommen.

Variante B — Flatpak

Flathub liefert einen offiziell gepflegten Flatpak-Build, der distro-unabhängig immer den aktuellen Stable bereitstellt. Das ist auf älteren Distros oder LTS-Releases der bequemste Weg an eine aktuelle Version, ohne selbst zu bauen.

shell Flatpak einrichten und Emacs installieren
# Flatpak und Flathub-Remote einmalig einrichten (falls noch nicht da)
sudo apt install flatpak                 # bzw. dnf, pacman, zypper
flatpak remote-add --if-not-exists flathub \
  https://flathub.org/repo/flathub.flatpakrepo

# Emacs installieren
flatpak install flathub org.gnu.emacs

# Starten
flatpak run org.gnu.emacs

Praktisch fast immer nötig sind ein paar Flatpak-Overrides, weil Emacs sonst nicht auf SSH-Schlüssel, System-Konfigurationen oder Entwicklungs-Verzeichnisse außerhalb von ~ zugreifen kann. Eine typische Anpassung:

shell Sinnvolle Overrides
# Lese-Zugriff auf SSH-Schlüssel (Magit, Tramp)
flatpak override --user --filesystem=~/.ssh:ro org.gnu.emacs

# Zugriff auf /etc (z. B. für Konfig-Editing)
flatpak override --user --filesystem=/etc org.gnu.emacs

# Zugriff auf ein zentrales Projekt-Verzeichnis außerhalb von $HOME
flatpak override --user --filesystem=/srv/projects org.gnu.emacs

Wer Flatseal als GUI nutzt, klickt die Overrides dort ohne Terminal-Befehle zusammen. Wichtig zu wissen: Der Flatpak-Build bringt seinen eigenen Pfad-Namespace mit — Tools wie git, ripgrep oder Sprach-Server müssen entweder aus dem Flatpak-SDK kommen oder per Host-Override eingebunden werden.

Variante C — Snap

Im Snap Store existiert ein emacs-Paket, das primär für Ubuntu gedacht ist. Es funktioniert grundsätzlich, ist aber durch das Snap-Confinement deutlich stärker eingeschränkt als Flatpak — vor allem Dateizugriff außerhalb von $HOME und Interaktion mit System-Diensten sind aufwändiger einzurichten.

shell Snap installieren
sudo snap install emacs --classic

Der --classic-Modus lockert das Confinement so weit, dass Emacs wie eine reguläre Anwendung agiert (voller $HOME-Zugriff, Host-Tools im Pfad). Ohne --classic ist das Paket im Alltag kaum brauchbar, weil Magit, Tramp und externe Linter blockiert werden.

Faustregel: Snap ist eine Notlösung, wenn weder Distro-Paket noch Flatpak in Frage kommen. Auf allen anderen Distros ist Flatpak die bessere Wahl, weil dort das Sandbox-Modell sauberer dokumentiert und mit flatpak override feiner steuerbar ist.

Variante D — Build from Source

Der Source-Build ist der einzige Weg, alle modernen Optionen frei zu kombinieren: Native Compilation (libgccjit), tree-sitter, pgtk für Wayland, Mailutils für movemail, optionale ImageMagick-Unterstützung. Für Power-User und alle, die mehrere Emacs-Versionen parallel halten wollen, ist er der Königsweg.

Schritt 1 — Build-Dependencies installieren

Welche Pakete dafür gebraucht werden, unterscheidet sich pro Distro. Eine Mindest-Auswahl für die drei großen Familien:

shell Debian/Ubuntu — Build-Deps
sudo apt install build-essential autoconf texinfo \
  libgtk-3-dev libgnutls28-dev libtree-sitter-dev \
  libgccjit-12-dev libjansson-dev libxml2-dev \
  libwebp-dev libjpeg-dev libpng-dev libtiff-dev libgif-dev \
  libxpm-dev libmagickwand-dev libsqlite3-dev
shell Fedora — Build-Deps
sudo dnf install gcc make autoconf texinfo \
  gtk3-devel gnutls-devel tree-sitter-devel \
  libgccjit-devel jansson-devel libxml2-devel \
  libwebp-devel libjpeg-turbo-devel libpng-devel libtiff-devel giflib-devel \
  libXpm-devel ImageMagick-devel sqlite-devel
shell Arch — Build-Deps
sudo pacman -S base-devel gtk3 gnutls tree-sitter \
  libgccjit jansson libxml2 libwebp libjpeg-turbo libpng \
  libtiff giflib libxpm imagemagick sqlite

Schritt 2 — Quellcode holen

shell Tarball oder git
# Variante 1: Offizieller Tarball vom GNU-Mirror
curl -O https://ftp.gnu.org/gnu/emacs/emacs-30.1.tar.xz
tar xf emacs-30.1.tar.xz
cd emacs-30.1

# Variante 2: Git-Clone für Pretests und eigene Builds
git clone https://git.savannah.gnu.org/git/emacs.git
cd emacs
git checkout emacs-30   # oder master für aktuellen HEAD
./autogen.sh

Schritt 3 — configure, make, install

shell Konfigurieren und bauen
./configure \
  --with-native-compilation=aot \
  --with-tree-sitter \
  --with-pgtk \
  --with-json \
  --with-mailutils \
  --with-imagemagick \
  --prefix=/opt/emacs-30

# Parallel bauen — nutzt alle Kerne
make -j"$(nproc)"

# Systemweite Installation in /opt/emacs-30
sudo make install

Statt des System-Paketmanagers überschreibt das --prefix=/opt/emacs-30 jeden Installations-Pfad sauber unter einem versionierten Wurzelverzeichnis. So lassen sich mehrere Major-Versionen parallel halten, ohne dass apt, dnf oder pacman durcheinanderkommen.

Schritt 4 — In den PATH einbinden

shell Symlink statt PATH-Erweiterung
sudo ln -s /opt/emacs-30/bin/emacs /usr/local/bin/emacs
sudo ln -s /opt/emacs-30/bin/emacsclient /usr/local/bin/emacsclient

Damit ist der selbst gebaute Emacs unter dem normalen Namen aufrufbar. Bei einem späteren Wechsel auf z. B. emacs-31 zeigt der Symlink auf den neuen Prefix, der alte Build bleibt unangetastet und kann jederzeit reaktiviert werden.

PGTK, X11 und lucid — welcher Toolkit-Build?

Bei einem Source-Build (und teils auch bei Distro-Paketen) ist zu entscheiden, gegen welches Widget-Toolkit Emacs gebaut wird. Drei Optionen sind relevant:

Buildconfigure-FlagWann sinnvoll
pgtk--with-pgtkWayland-Sessions; HiDPI-Skalierung wie native GTK-Apps; modernes IME-Handling
GTK3 / X11(Default ohne --with-pgtk)X11-Sessions; XWayland-Fallback; maximale Kompatibilität mit Legacy-Setups
lucid--with-x-toolkit=lucidminimaler X-Build mit Athena-Widgets; klassischer Look, geringste Abhängigkeiten

Eine pragmatische Faustregel:

  • Wayland-Distro (Fedora, Ubuntu 24.04+, openSUSE Tumbleweed mit Wayland): --with-pgtk — Emacs läuft dann nativ auf dem Wayland-Compositor, ohne den XWayland-Umweg.
  • X11-Session oder gemischte Umgebung: der Standard-GTK3-Build, weil er sich in beiden Welten zurechtfindet.
  • Server, Container, sehr alte Hardware: lucid (oder direkt --without-x für die reine Terminal-Variante).

Wichtig: --with-pgtk und der klassische X11-Build schließen sich gegenseitig aus — Emacs muss für eine der beiden Welten konfiguriert sein. Wer beide braucht, baut zwei separate Prefixes (z. B. /opt/emacs-30-pgtk und /opt/emacs-30-x11).

Erster Start und Versions-Check

Nach der Installation lohnt ein kurzer Sanity-Check im Terminal:

shell Versions-Check
emacs --version
Output
GNU Emacs 30.1
Copyright (C) 2025 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.

Für eine reine Terminal-Session — sinnvoll auf Servern oder über SSH — startet emacs -nw Emacs ohne Fenster-System (-nw = „no window system"). Ein einfaches emacs ohne Argumente öffnet das GUI-Fenster (sofern verfügbar) mit dem Startbildschirm, der sich selbst erklärt und sich über das Menü auch ohne Vorkenntnisse wieder schließen lässt.

Welche Build-Features in der laufenden Installation aktiviert sind, listet Emacs intern in der Variable system-configuration-features und in system-configuration-options auf. Eine schnelle Shell-Variante:

shell Build-Features anzeigen
emacs --batch --eval '(message "%s" system-configuration-features)'

In der Ausgabe sollten NATIVE_COMP, TREE_SITTER, GTK3 (oder PGTK) und GNUTLS auftauchen — das sind die heute relevanten Features.

systemd-User-Unit für den Daemon

Ein populärer Linux-Workflow ist, Emacs einmal als Hintergrund-Daemon zu starten und neue Frames per emacsclient blitzschnell aufzurufen. Auf systemd-Distros — also praktisch allen außer Alpine — ist der saubere Weg dafür eine User-Unit, die mit der Login-Session startet.

shell ~/.config/systemd/user/emacs.service
[Unit]
Description=GNU Emacs Daemon
Documentation=info:emacs man:emacs(1)

[Service]
Type=notify
ExecStart=/usr/bin/emacs --fg-daemon
ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
Restart=on-failure
Environment=SSH_AUTH_SOCK=%t/keyring/ssh

[Install]
WantedBy=default.target

Aktiviert wird die Unit über das normale systemd-User-Interface:

shell Daemon aktivieren
systemctl --user daemon-reload
systemctl --user enable --now emacs.service

# Status prüfen
systemctl --user status emacs.service

# Ersten Frame an den Daemon anhängen
emacsclient -c

Der Pfad zu emacs (/usr/bin/emacs) muss zur Installation passen — bei einem Source-Build aus Abschnitt 05 ist es typischerweise /opt/emacs-30/bin/emacs bzw. der oben angelegte Symlink. Das vollständige Setup mit Auto-Start, mehreren Frames, GUI- und Terminal-Clients und passender Desktop-Verknüpfung ist im späteren Kapitel Daemon und emacsclient beschrieben; hier reicht das Wissen, dass der Modus existiert und mit einer einzigen Unit-Datei dauerhaft eingerichtet werden kann.

Häufige Stolperfallen

Ubuntu LTS und Debian Stable hinken oft 1–2 Major-Versionen hinterher

Auf Ubuntu LTS und Debian Stable ist emacs aus dem Default-Repo regelmäßig deutlich älter als der aktuelle Stable-Release — schlicht, weil die Distro Major-Versionen einfriert. Wer auf einer LTS bleiben, aber den aktuellen Emacs nutzen will, hat drei Optionen: ein PPA wie ppa:ubuntuhandbook1/emacs, den Flathub-Build oder einen Source-Build mit eigenem Prefix. Das Repo-Paket zu verwenden ist trotzdem nicht falsch — viele Pakete laufen jahrelang ohne Probleme auf der älteren Version.

Build-Deps werden gerne vergessen: libgccjit, gnutls, tree-sitter

Beim Source-Build sind die häufigsten Fehlanzeigen libgccjit-*-dev (ohne das schaltet configure Native-Compilation stillschweigend ab), libgnutls28-dev (HTTPS-Pakete-Download bricht weg) und libtree-sitter-dev (alle *-ts-mode-Major-Modes fallen aus). Wer am Ende des configure-Laufs den Zusammenfassungs-Block sorgfältig liest, sieht für jedes Feature ein yes oder no und kann fehlende Pakete sofort nachziehen, bevor make läuft.

Native Compilation braucht libgccjit auch zur Laufzeit

--with-native-compilation braucht libgccjit nicht nur beim Bauen, sondern auch beim Ausführen — die JIT-Kompilation findet im laufenden Emacs statt. Auf Debian/Ubuntu ist das Paket libgccjit0 (Laufzeit) zusätzlich zu libgccjit-<version>-dev (Build). Wer den Emacs-Binary auf eine andere Maschine kopiert, muss dort libgccjit0 separat installieren, sonst startet *.eln-Caching nicht.

Flatpak-Sandbox: kein direkter Zugriff auf /etc und ~/.ssh

Der Flatpak-Build sieht standardmäßig nur $HOME (mit Ausnahmen wie ~/.ssh, das explizit ausgeklammert ist). Magit-Operationen gegen entfernte Repos, Tramp-Verbindungen über SSH und das Editieren von Dateien unter /etc schlagen ohne passende flatpak override-Erweiterungen fehl. Wer hier viel Zeit verliert: in 90 % der Fälle ist es ein fehlender Filesystem-Override.

Wayland und IME-Eingabe verhalten sich unter pgtk anders als X11

Der pgtk-Build nutzt GTKs eigenes Input-Method-Framework — das ist für CJK-Eingabe (ibus, fcitx5) ein echter Fortschritt gegenüber dem X11-Build, kann aber auf Systemen mit gemischten IM-Konfigurationen zu Überraschungen führen (z. B. doppelt aktivierter Compose-Key, Emoji-Picker, der nicht auftaucht). Bei IME-Problemen lohnt der Test, ob GTK_IM_MODULE=ibus oder =fcitx in der User-Umgebung gesetzt ist.

Mehrere Emacs-Versionen parallel: update-alternatives statt PATH-Tricks

Auf Debian/Ubuntu ist update-alternatives der saubere Weg, zwischen mehreren Emacs-Installationen zu wechseln — etwa zwischen Repo-Paket und Source-Build unter /opt/emacs-30. Damit bleibt which emacs konsistent, man emacs zeigt die richtige Variante, und Skripte, die /usr/bin/emacs direkt aufrufen, finden weiter die zuletzt gewählte Version.

Versionierter Prefix beim Source-Build verhindert verstopfte /usr/local-Stände

Wer ohne --prefix baut, landet in /usr/local/bin, /usr/local/share/emacs/<version> usw. Ein zweiter Build derselben Version überschreibt sich selbst, ein Major-Wechsel hinterlässt Reste. Mit --prefix=/opt/emacs-30 liegt jede Version sauber in ihrem eigenen Baum; deinstalliert wird durch Löschen des Verzeichnisses und Entfernen des Symlinks aus /usr/local/bin — ohne Spurensuche.

Snap-Confinement bricht Tramp, externe Linter und Magit-Helfer

Snap ohne --classic blockiert Zugriff auf Host-Binaries — git, ssh, rg, Sprach-Server liegen außerhalb der Sandbox. Selbst mit --classic bleibt das Snap-Paket schlechter integriert als Flatpak oder Distro-Paket. Für Server-Setups und produktive Workstations ist Snap heute keine empfohlene Wahl mehr.

Weiterführende Ressourcen

Externe Quellen

Verwandte Artikel

/ Weiter

Zurück zu Grundlagen

Zur Übersicht