Zu den wertvollsten Verbesserungen für Emacs, auf die ich in den letzten Wochen gestoßen war, gehört die Möglichkeit, einen harten Zeilenumbruch leicht wieder rückgängig machen zu können. Das kann Emacs nämlich nicht von Haus aus, Emacs kann nur neu umbrechen und umbrechen und umbrechen. Um einen Umbruch zurückzunehmen, hatte ich früher die wikipedia-unfill-*-Befehle aus dem Wikipedia Mode von Chong Yidong und Uwe Brauer benutzt. Das setzt aber voraus, dass man den Wikipedia Mode zuvor geladen hat. Einfacher zu handhaben ist dagegen der Vorschlag von Stefan Monnier, der im EmacsWiki überliefert ist:

(defun unfill-paragraph (&optional region)
  "Takes a multi-line paragraph and makes it into a single line of text."
  (interactive (progn (barf-if-buffer-read-only) '(t)))
  (let ((fill-column (point-max))
        ;; This would override `fill-column' if it's an integer.
        (emacs-lisp-docstring-fill-column t))
    (fill-paragraph nil region)))
(define-key global-map "\M-1" 'unfill-paragraph)

Man muss den Absatz nicht markieren, die Funktion greift dort, wo der Cursor gerade steht. Als eine schöne motorische Eselsbrücke hat sich bewährt, die neue Funktion global an M-1 zu binden, was direkt neben dem händischen Umbruch per M-q liegt.

Die Umstellung meiner LaTeX-Einführung von HTML auf Org-Mode ist abgeschlossen. Das Projekt steht jetzt als l2intro auf GitHub und kann direkt für meine Website exportiert und installiert werden, ohne weitere Nachbearbeitung.

Bin noch unsicher, ob ich es damit bewenden lasse oder ob ich auch die restliche Website in Org überführe und dann in Zukunft komplett als Publishing-Projekt exportiere.

Es gibt mehrere Completion Frameworks für den GNU Emacs. Sie sollen die Auswahl von Dateien, Buffern, von Variablen und Funktionen erleichtern. Und weil sie immer wieder empfohlen, teilweise geradezu gehypt werden, habe ich die wichtigsten ausprobiert.

• Ido ist Teil von Emacs. Man muss es also nicht mehr hinzu installieren, sondern nur noch aktivieren. Es verändert den Mini-Buffer, indem eine Auswahl in horizontaler Anordnung gezeigt wird, und man kann diese dann weiter einschränken, indem man weiter tippt, je nach Konfiguration genau oder fuzzy, oder indem man mit dem Cursor nach rechts oder links und RET auswählt. Viel mehr macht Ido nicht. Man kann damit leben.
• Helm von Thierry Volpiatto wird vielerorts wärmstens empfohlen. Helm hieß früher Anything und wurde dann umbenannt. Es schaltet sich in sämtliche M-x-Dialoge ein und sorgt für eine Autovervollständigung in eigenen Buffern. Helm blendet alle verfügbaren Datei- und Befehlsnamen ein, die irgendwie zum Suchstring passen. Die Auswahl erfolgt über eine Auswahlliste in einem eigenen Buffer, nicht über den Mini-Buffer, in den man den Suchstring eintippt – das ist zu Anfang etwas verwirrend. Ein Nachteil liegt in der Unruhe, die in die Bedienung kommt. Ich meine, vor allem durch Helm wird die Bedienung sogar eher erschwert als erleichtert.
• Die dritte Lösung, die ich getestet hatte, ist Ivy von Oleh Krehel, das zusammen mit den weiteren Paketen Counsel und Swiper eingesetzt wird. Ivy wurde offenbar von Helm inspiriert, denn der Mini-Buffer wird auch hier zu einer Liste, die man direkt durchsuchen kann; dabei wird sie live gelichtet, und am Ende bleiben nur noch die Datei- und Buffer-Namen übrig, die irgendwie zur Eingabe passen. Beim Durchsuchen eines Buffers mit Swiper werden stattdessen die passenden Zeilen angezeigt, die zu einem Suchmuster passen. Das ist tatsächlich eine Verbesserung der inkrementellen Suche, die ich zu schätzen gelernt habe.
• Das vierte Completion Framework ist Vertico von Daniel Mendler in Verbindung mit den Paketen Marginalia, Consult, Embark und Orderless. Vertico baut soweit wie möglich auf den bestehenden Funktionen in Emacs auf, bietet sie aber anders dar und erlaubt eine sehr dynamische und interaktive Auswahl. Praktisch ist, dass Marginalia die Kurzbeschreibungen von Paketen, Variablen und Funktionen einblendet, das erleichtert den Überblick erheblich. Insgesamt erinnert es mich aber zu sehr an Helm, das ich nicht mag.

Und so blieb ich am Ende erst einmal bei Ivy, das sich einerseits noch nach Emacs anfühlt, das andererseits aber auch per Swiper eine sehr schöne und nützliche Verbesserung der Isearch mitbringt. Die drei anderen Lösungen habe ich aber noch nicht deinstalliert, sondern erstmal beibehalten, um immer mal wieder testen zu können. Es mag sein, dass sich meine Bedarfe im Laufe der Zeit verändern. Außerdem ist es leichtes Gepäck, denn die nicht genutzten Pakete werden nicht geladen, wenn man sie im Init-File auskommentiert hat.

Der Verzicht auf Completion Frameworks hat aber auch vieles für sich, denn die Bedienung, bei der man Vervollständigungen per TAB und die History der Auswahl per Cursor hoch/runter bedient, ist man schon so lange vom Terminal gewöhnt, dass sie sehr eingängig ist und einfach. Außerdem wird der Zugriff auf das Dateisystem durch die Completion umständlicher. Mein Dateisystem ist Teil meines Wissensmanagements und erschließt das Material, mit dem ich arbeite, auch inhaltlich. Alle Frameworks verändern die Bearbeitung des Speicherpfads im Mini-Buffer, so dass es etwas schwieriger wird, im Pfad zu navigieren, um eine Datei in einem anderen Verzeichnis neu zu speichern. Vieles muss sich also bei der Bedienung neu einspielen, wenn man als erfahrener Emacs-Benutzer solche Lösungen zum ersten Mal einsetzt.

Weniger ist mehr.

Kurz vor dem Wochenende traf die dritte Auflage des LaTeX Companion, des TLC3, ein. Zwei Bände mit zusammengenommen gut 1900 Seiten. 18 Jahre nach dem Erscheinen der deutschen Übersetzung der zweiten Auflage. Ein enormer Gewinn für alle Benutzer und eine große Freude, ein so sorgfältig hergestelltes Buch zu bekommen.

Wobei es nicht ganz einfach war, den Titel zu bestellen, denn Addison-Wesley oder besser gesagt: Pearson ist auch nicht mehr ganz, was es mal war. Das Buch ist zwar in Deutschland über den Buchhandel bestellbar, es wird hierzulande aber nicht gelagert, sondern jeweils direkt beim Verlag aus den USA beschafft. Das sorgt für eine lange Lieferzeit und für vergleichsweise hohe Kosten. Und auch für ungewöhnlich schwankende Kosten. Wenn man die deutsche Buchpreisbindung gewöhnt ist, mag es merkwürdig anmuten, aber die Preisunterschiede zwischen den Buchhändlern sind doch beträchtlich.

Am ärgerlichsten ist aber wohl, dass der Transfer der Metadaten vom amerikanischen zum deutschen Buchhandel nicht so richtig klappen will. Wer das Werk bestellt, möge sich deshalb, bitte, nicht kirre machen lassen, es gibt mehrere Angebote vom Verlag: Man kann beide Bände separat bestellen, beide haben eine eigene ISBN, und es gibt ein Bundle mit beiden, und dann gibt es nochmal ein Bundle zusammen mit der E-Book-Ausgabe, das wäre dann also sozusagen die vollständigste aller Ausgaben. Wer die Auskunft erhält, der zweite Band sei nicht lieferbar, möge ihn reklamieren. Es gibt ihn wirklich, er liegt gerade neben mir auf dem Schreibtisch. Also nicht nur als E-Book, sondern als Book-Book.

Wer sich für LaTeX interessiert, möchte doch wahrscheinlich gerne ein gedrucktes Buch in Händen halten, zumal bei dem besagten Umfang. Fest gebunden auf gutem Papier mit einem schönen dunkelroten Lesebändchen. Und dann hat es also doch noch deutlich vor Weihnachten geklappt. Ich freue mich wirklich darauf! Und alle Beispiele aus dem TLC3 gibt es auf CTAN.

Übrigens habe ich die knappe Einführung in LaTeX, die ich seit ein paar Jahren auf meiner Homepage anbiete, endlich einmal wieder aktualisiert. Viele Weblinks gingen nicht mehr. Einige Angaben waren ebenfalls überholt. Bei der Gelegenheit habe ich den Text von HTML auf Org-Mode umgestellt. Sowohl die Quelle als auch der leicht nachbearbeitete HTML-Export aus Org stehen auf GitHub bereit. Und bei der nächsten Version werde ich auch die Teile, die ich heute noch händisch angegangen hatte, soweit wie möglich in Org umsetzen. Vielleicht kann ich meine gesamte Website als Publishing-Projekt auf Org umstellen. Wahrscheinlich erhalte ich auch beim Lesen des TLC3 eine paar Anregungen, die in den Text einfließen können, ohne ihn zu sehr auszudehnen.

Bei der Gelegenheit habe ich meine Homepage noch mit einem Dark Mode versehen. Das war per @media (prefers-color-scheme: dark) {...} tatsächlich viel einfacher, als ich gedacht hätte.

Ich stelle mir gerade parallel eine ebenso kurze Einführung in die Installation von Emacs unter macOS vor, in der ich meine Erfahrungen aus den letzten Wochen zusammenfassen könnte, die ich ja teilweise hier auch verbloggt hatte. Ich mag die alte Tradition der gentle introductions sehr, von denen es früher ganz viele im Netz gab, zu allen möglichen Themen. Blogs, Wikis und Webforen sind hilfreich, aber letztlich sind es nur gesammelte Bruchstücke, es fehlt meistens der größere Überblick über ein Thema. Still digging!

Zu den praktischsten neuen Paketen, die mir in den letzten Wochen untergekommen sind, gehört mit deutlichem Abstand der Company Mode. Er kam auf mein System, als ich die Python-Umgebung elpy nachinstallierte, die es einsetzt. Beim Tippen werden Vorschläge aus dem restlichen Text in diesem oder auf Wunsch auch aus weiteren Buffern desselben Modes angeboten, die man auswählen und annehmen oder verwerfen kann. Die Vorschläge können also auch ein Projekt mit einbeziehen, das aus mehreren Dateien besteht. Das funktioniert sowohl bei Code als auch bei Fließtext, auch in längeren Kommentaren, und für mich als Vielschreiber ist das Paket natürlich ein Muss. Damit kann ich das Paket dabbrev-expand deutlich erweitern, das kein Frontend hatte, bei dem der Text automatisch so schön eingeblendet wurde – man musste einen Keystroke ausführen, um Autocomplete auszulösen. Company kann so konfiguriert werden, das auch Groß- und Kleinschreibung beachtet werden. Mit anderen Worten: Ich bin glücklich.

Zu den schönsten Paketen für den GNU Emacs, die mir untergekommen sind, gehört golden-ratio von Roman Gonzalez. Gestern kam Version 1.0.1 auf ELPA. golden-ratio nimmt sich des Zuschnitts der Buffer im Verhältnis zueinander an, wenn innerhalb eines Frames in Emacs mehrere Buffer gleichzeitig geöffnet sind.

Das Paket sorgt für zweierlei: Es gibt dem Buffer, in dem man gerade arbeitet, den meisten Platz. Und es legt für das Verhältnis der Buffer-Höhen zueinander den Goldenen Schnitt zugrunde. Und das alles dynamisch und direkt bei der Benutzung, was sehr praktisch ist und auch ziemlich elegant aussieht. Besonders zu empfehlen, wenn man beim Schreiben zum Beispiel zwischen einem Org-Buffer und einem Programm in elpy und mehreren Test-Buffern hin und her schaltet.

Ich war ja skeptisch, aber nach diesem Härtetest bin ich sehr gespannt, ob es tatsächlich Pakete gibt, mit denen sich golden-ratio nicht verträgt – kann mir das aber mittlerweile kaum noch vorstellen. golden-ratio ist wohl schon ziemlich gut getestet worden.

Da war übrigens noch was: Es gab ein Update zu den Builds bei emacsformacosx.com. Ich war so sehr mit dem Konfigurieren und Herumspielen beschäftigt, dass ich das gar nicht mehr bemerkt hatte. Bei Version 29.1, die David Caldwell bereitgestellt hatte, war, dem ChangeLog zufolge, die brandneue SQLite-Unterstützung nicht enthalten. Die hatte er erst in einem Build vom 16. August 2023 nachgereicht, die er unter dem Tag 29.1-1 veröffentlicht hat. Diese Versionsnummer gibts offiziell zwar nicht, aber hier doch schon. Installieren tut nicht weh. Auch Version 29.1-1 läuft tadellos.

Die Mailinglisten waren schon ganz erheblich geschrumpft, als sich der Traffic erst in die Webforen und dann in die Sozialen Netzwerke und die Instant-Messenger-Dienste verschob. Obwohl auch Diskussionen über Emacs zu einem großen Teil auf StackExchange und Reddit stattfinden, laufen die Projekt-Mailinglisten aber immer noch sehr gut. In den letzten vier Wochen liefen über emacs-devel, help-gnu-emacs, emacs-orgmode und die auctex-Listen fast 2000 Nachrichten. Und zwar ziemlich gehaltvolle Nachrichten.

Freilich ist emacs-devel mitunter eher so eine Art Seifenoper für alle, die die Freie-Software-Szene schon etwas länger verfolgen. Auffällig ist vor allem die Fixierung auf hauseigene Lösungen, die ganz klar nicht zielführend sein kann. Derzeit wird dort beispielsweise besprochen, ob man Texinfo durch Org-Mode ersetzen könne. Man verspricht sich davon entweder (a) gar nichts oder aber (b) einen verstärkten Zustrom von Entwicklern, die sich bisher von einer Mitarbeit an GNU-Projekten abgeschreckt fühlten, weil sie nicht bereit waren, extra Texinfo zu lernen, um auch die Dokumentation regelkonform abliefern zu können. Das ist nicht ganz abwegig. Es ist ziemlich genau zwanzig Jahre her, dass ich mal die Überarbeitung eines Manuals abgebrochen hatte, noch bevor ich damit anfing, weil ich mir das mit Texinfo nicht antun wollte. Ich hatte gedacht, es wäre bloß LaTeX. Und jetzt ausgerechnet Org-Mode als Ersatz. Eine eierlegende Wollmilchsau, eine Mischung aus Outliner, Exporter und Agenda-Planer, die erst einmal durch Nacharbeit noch einmal gehörig zurechtgebogen werden müsste, um Texinfo, das für einen sehr speziellen Zweck entwickelt worden war, ersetzen zu können. Wo doch schon längst alle in Markdown schreiben, in irgendwelchen Varianten, zugegeben, aber irgendwie geht es doch.

Nachdem ich nun in den letzten Wochen viel mit Org gearbeitet hatte, habe ich mir nun endlich auch einmal den Markdown-Mode in Emacs eingerichtet. Was ich noch nicht wusste: Er stammt von demselben Entwickler, der auch das Notizen-Frontend Deft geschrieben hat. Deft hatte ich getestet, gewogen und dann aber doch für zu schwer befunden, will sagen: Viel zu Umfangreich und unnötig. Wenn ich alle meine Notizen sowieso in einem Deft-Verzeichnis sammle, kann ich mir auch gleich ein Bookmark ins Dock setzen und die Org-, Markdown- oder Text-Dateien von dort aus direkt öffnen und sie händisch in ein Archiv-Unterverzeichnis verschieben. Hierzu bot Deft keine zusätzliche Funktion, die nicht schon durch das Betriebssystem bereit gestanden hätte. Also eher kein Deft-Mode.

Aber eine gute Gelegenheit, der ewigen Konkurrenz zwischen Org und Markdown einmal nachzuspüren. Ist da etwas dran? Nach mehreren Wochen finde ich, dass Markdown zum bloßen Schreiben, etwa um so einen Blogpost wie diesen hier vorzubereiten, etwas besser geeignet ist als Org, weil die Syntax stringenter und auf den Text und seine Gliederung beschränkt ist und dadurch deutlich übersichtlicher bleibt. Ein Org-Dokument ist in kurzer Zeit überflutet mit Anmerkungen, Tags, Properties, Drawers und Zeitstempeln verschiedener Art. Dadurch wird der Text immer unübersichtlicher, auch wenn er durch Syntaxhighlighting optisch entsprechend aufbereitet worden ist. Auf das Emacs-Theme, das man verwendet, kommt es dann auch nicht mehr wirklich an. Es sei denn, man verzichtete grundsätzlich auf all die Ergänzungen, die Org bereithält, und setzt sie nur ausnahmsweise ein. Dann wären Org und Markdown insoweit fast identisch.

Um auf die Diskussion über Org-Mode vs. Texinfo zurückzukommen: Eigentlich stellt sich die Frage schon längst nicht mehr in dieser Weise, seit alle Welt Markdown schreibt. Seit sogar CTAN für fast jedes Paket ein README.md bereithält und im Webbrowser anzeigt, weil die Daten sowieso vorhanden sind. Die meisten Pakete werden auf GitHub gehostet, weniger kommen von GitLab oder vom Entwickler-eigenen GitLab. Und bringen daher Markdown standardmäßig mit. GitHub Pages hat ein weiteres getan.

Aber auf emacs-devel fragen sie sich: Org-Mode oder Texinfo?

BTW: Rezension: „Der Vorweiner“ von Bov Bjerg – lesen!

Einen Blogpost von Charles Choi fand ich hilfreich, um einfache Timestamps, geplante Tasks und solche mit einer Deadline in Org-Mode besser auseinanderzuhalten.

Auffällig, dass die Wiedervorlage in Org-Mode gar nicht erwähnt wird. Es ist die bei weitem häufigste Projektphase im Alltag. Ständig ist man damit beschäftigt, nochmal anzurufen, anzumailen, weil man keine Rückmeldung erhalten hat oder weil schlicht niemand zu erreichen war. Habe dem abgeholfen.

Beim Umstieg von macOS Monterey auf Ventura war auffällig, dass die neu hinzugekommenen Programme, wie beispielsweise die Uhr, nicht mehr konfigurierbar sind. Es gibt kein Preference Pane, man kann sie nur noch so benutzen, wie sie angeboten werden. Ich kann mir also beispielsweise beim Timer nicht einstellen, ob er digital (mit rückwärts laufenden Zahlen) oder analog (mit rückwärts laufenden Uhrzeigern auf einem Ziffernblatt) dargestellt werden soll.

Das ist beim Emacs ganz anders. Konfigurationsfragen stellen sich ständig. Mit dem Emacs zu arbeiten, heißt, ihn zu konfigurieren, und dazu gibt es eine eigene Sprache, Emacs Lisp.

Fangen wir also beim Anfang an. Dieser Teil meiner Reise durch Emacs und Umgebung begann beim Einrichten von Flyspell. Das ist die Rechtschreibprüfung, die Emacs von Hause aus mitbringt. Ich hatte zwar meine Dissertation seinerzeit vollständig ohne Rechtschreibkorrektur (und übrigens auch ohne die Literaturverwaltung BibTeX – Biblatex und Biber gabs damals noch nicht) geschrieben. Aber besser wäre gewesen mit, wie ich mittlerweile weiß. Aquamacs greift sogar auf die Rechtschreibprüfung von macOS zurück, was auf der Plattform freilich optimal ist. Aber wir wollen ja jetzt erstmal lieber nur mit freien und quelloffenen Lösungen arbeiten, und das heißt in diesem Fall: mit aspell.

Der Anlass zum näheren Hinschauen waren letztlich zwei Probleme, die beim Konfigurieren meines Emacs auftraten: Flyspell tat nicht einfach mal so eben, was es soll. Und nachdem ich das gelöst hatte, kam noch ein weiteres Problem hinzu: Beim Schreiben der nächsten Folge meiner Neuen Pakete auf CTAN für die TeXnische Komödie stieß ich auf die Neuerung, dass dtk.cls nun das Kompilieren mit LuaLaTeX nicht nur nahelegt, sondern verlangt. LuaTeX brach seinen Lauf aber beim Aufruf aus dem Emacs schnell wieder ab und verabschiedete sich mit einem Output von null Seiten. Die vorläufige Lösung für beide Probleme hatte ich schon vor ein paar Tagen vorgestellt.

Die Merkwürdigkeiten, auf die ich damals gestoßen war, ließen mich freilich nicht ruhen, ich las weiter und weiter und stieß dabei im Emacs-Manual im Kapitel zu Emacs unter macOS auf einen Abschnitt, der das grundlegende Problem ansprach, den Leser dann am Ende aber auch ziemlich allein zurücklässt:

Many programs which may run under Emacs, like latex or man, depend on the settings of environment variables. If Emacs is launched from the shell, it will automatically inherit these environment variables and its subprocesses will inherit them from it. But if Emacs is launched from the Finder it is not a descendant of any shell, so its environment variables haven’t been set, which often causes the subprocesses it launches to behave differently than they would when launched from the shell.

For the PATH and MANPATH variables, a system-wide method of setting PATH is recommended on macOS, using the ‘/etc/paths’ files and the ‘/etc/paths.d’ directory.

Wer das Vorgehen beim Konfigurieren von Emacs mag, das sich zwischen beinahe detektivischer Recherchearbeit, Programmieren, Technik, Informationswissenschaft und Praxis bewegt, für den könnte der Emacs ebenfalls der Editor der Wahl sein. Für alle anderen möglicherweise nicht. Typisch ist nicht nur, dass man immer wieder mit solchen halben Sachen wie dem vorstehenden Absatz ziemlich dumm dasteht, sondern auch, dass sehr viele veraltete Empfehlungen und Code-Schnipsel im Netz um Umlauf sind, die sich auf ältere Versionen von Emacs oder von Ergänzungspaketen beziehen. Da werden Variablen konfiguriert, die es mittlerweile gar nicht mehr gibt, was im einfachsten Falle schlicht folgenlos bleibt, im schlechteren Fall aber zu Fehlermeldungen, die ein blutiger Laie kaum beheben könnte. Es werden Befehle bereitgestellt, die ehemals Probleme umgehen sollten, die aber in neueren Versionen von Emacs gar nicht mehr bestehen. Manchmal ist nicht sicher, ob eine Empfehlung, die vermeintlich funktioniert, auch heute immer noch die bestmögliche Lösung für ein bestimmtes Problem ist. Man sollte deshalb tunlichst darauf achten, aus welcher Zeit eine Empfehlung stammt und ob sich seitdem in der Emacs- und in der Paket-Entwicklung etwas getan hat – und falls ja, was?

Immerhin gibt es für das Problem, auf das das Emacs-Manual hinweist, wiederum ein Paket. Ich fand es, als ich später, nach meinem letzten Blogpost zum Thema, eigentlich nach etwas ganz anderem suchte. Nachdem die Rechtschreibprüfung einigermaßen lief, hätte ich sowas gerne auch für Quelltexte gehabt und stieß auf Flymake (schon eingebaut) und Flycheck (nachzuinstallieren). Und auf der Website von Flycheck finden wir folgenden Hinweis:

Flycheck can’t find any programs in GUI Emacs on MacOS

Try to install and configure exec-path-from-shell to make a GUI Emacs inherit the $PATH environment variable from your shell configuration.

The issue is that due to the special way MacOS starts GUI programs a GUI Emacs does not inherit the environment variables from the shell configuration so Emacs will lack some important entries in $PATH, most notably /usr/local/bin/ where Homebrew, NPM and many other package managers put binaries in.

The exec-path-from-shell works around this issue by extracting environment variables from a shell session and inject them into the environment of the running Emacs instance.

Und damit bekommt das Problem eine neue Wendung. Das Paket, das dort erwähnt wird, ist schnell installiert und tut tatsächlich, was es soll (und sogar ein bisschen mehr). Und dadurch werden einige Anweisungen, die ich ursprünglich brauchte, überflüssig. Während sich eine andere als äußerst hinderlich erwiesen hatte. Man kann nämlich das Language Environment in Emacs nicht nur auf Sprachen, sondern auch auf Kodierungen einstellen, also auch auf UTF-8 direkt, wie man hier sieht. Erst damit werden alle neuen Dateien unmittelbar in UTF-8 angelegt. Für die Festlegung auf Unicode braucht es freilich noch mehr Zeilen Code, aber seitdem funktioniert alles wunderbar.

Die derzeit richtige Lösung, mit der alle Mac-spezifischen Ärgernissen, die mir bisher untergekommen sind, abgeholfen wird, wäre demnach wohl die folgende, wobei ich mir nicht sicher bin, ob dabei immer noch Teile mittlerweile obsolet und daher unnötig sind, ich belasse diese Zeilen aber vorsorglich mal in meiner .emacs, denn sie schaden jedenfalls nicht:

(require 'exec-path-from-shell)
(exec-path-from-shell-initialize)
(set-default-coding-systems 'utf-8)
;;
;; Ist folgendes veraltet? Jedenfalls schadet es nicht.
;;
(prefer-coding-system 'utf-8)
(set-default-coding-systems 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(if (boundp 'buffer-file-coding-system)
    (setq-default buffer-file-coding-system 'utf-8)
  (setq default-buffer-file-coding-system 'utf-8))
(setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING))
;;
;; Beim Öffnen von Dateien aus dem Finder per Doppelklick werden neue
;; Buffer im bestehenden Frame geöffnet: 
;;
(setq ns-pop-up-frames nil)
;;
;; Tastaturbelegung
;;
(setq mac-command-modifier 'meta) ;; Cmd/Apfel wird zum Meta Key
(setq mac-option-modifier nil) ;; Option hat keine Funktion in Emacs
(setq ns-alternate-modifier 'none)
;;
;; für Flyspell/aspell:
;;
(setenv "LANG" "de_DE.UTF-8")
(set-locale-environment "de_DE")
(set-language-environment "UTF-8")
(add-hook 'text-mode-hook 'flyspell-mode)

Ob ich nun noch Flymake oder Flycheck verwenden werde, mag die Zukunft weisen.