Eine Suchanfrage lief ins Leere. Statt einer Trefferliste, erschien die Startseite von MetaGer:

Die Suchmaschine MetaGer ist jetzt nur noch werbefrei verfügbar! Mehr erfahren …

Mehr dazu gabs im Blog des Trägervereins zu lesen, bei Heise Online und beim Spiegel. Yahoo stelle sein Deutschlandgeschäft ein und habe deshalb den Vertrag mit MetaGer gekündigt. Damit sei ihnen die einzige nennenswerte Einnahmequelle abhandengekommen. Deshalb müssten nun alle Mitarbeiter entlassen werden. Der freie, weil werbefinanzierte Zugriff auf MetaGer sei nicht mehr zu gewährleisten. Der Dienst werde in der bisherigen Form eingestellt.

Ich weiß gar nicht, wie lange ich MetaGer schon genutzt habe. Mit den kommerziellen Suchmaschinen hatte ich mich noch nie wohlgefühlt. Der Datenhandel. Der gläserne User. Das undurchsichtige Geschäft auf Gegenseitigkeit, bei dem mir die Plattform verschweigt, was sie von meinen Daten abgreift und was sie an wen weitergibt und was für Folgen das für mich später an welchen Stellen haben könnte. Für eine Handvoll URLs.

Wenn man sich davon freimachen könnte, indem man eine Suchmaschine abonniert wie einen anderen Dienst, eine Datenbank beispielsweise, denn was ist das anderes als eine Datenbank von Weblinks, die man durchsuchen kann, wäre das eine feine Sache.

In der Tat bietet der Trägerverein von MetaGer weiterhin die Nutzung für Vereinsmitglieder an. Oder per Token pro Suche über einen Schlüssel, der den Zugriff erlaubt. Aber hier fehlt es auf einer andere Ebene an Vertrauen. Denn ein Verein, der so wenig vorausschauend arbeitet, dass er es über einen so langen Zeitraum hinweg nicht versteht, seine treuesten Benutzer rechtzeitig auf diese existenzielle Bedrohung hinzuweisen, um sie zu Stakeholdern zu machen, die die Möglichkeit gehabt hätten, den Bestand des Projekts zu sichern, und damit so vorhersehbar gegen die Wand fährt, die da schon so lange im Weg steht, ein solcher Verein bietet sehr wahrscheinlich keine Gewähr für eine aussichtsreiche Zukunft der freien Websuche mehr. Sie haben so lange Zeit gehabt, das zu ändern.

Ich brauche einen anderen Workflow. Als erstes teste ich fairsuch.net und qwant.com, und dann sehe ich weiter. Still digging.

Update vom 2024-09-15: fairsuch.net ist vorläufig ein brauchbarer Ersatz für MetaGer.

Update vom 2024-09-20: fairsuch.net kann man nicht in Thunderbird einbinden. Dort also: DuckDuckGo.

Upgrade von macOS Ventura auf macOS Sonoma.

• Upgrade der Command Line Tools.

• Upgrade von Homebrew.

• Der selbstkompilierte Emacs 29.3 startet nicht mehr.

• Ich versuche es mit einem Neubau.

• Es stellt sich heraus, dass ein selbstgebauter Emacs unter Sonoma nur noch startet, wenn man zuvor das tar.gz-Archiv auf der Kommandozeile entpackt hatte. Das Archivierungstool, das per Doppelklick aus dem Finder startet, ruft den Gatekeeper auf den Plan, und zwar auch wenn der Gatekeeper zuvor deaktiviert wurde? Hm. Neubau erfolgreich:

  GNU Emacs 29.3 (build 1, aarch64-apple-darwin23.5.0, NS appkit-2487.60 Version 14.5 (Build 23F79)) of 2024-06-09

• Die Peripherie funktioniert.

• Aber das Terminalfenster startet jetzt immer im Hintergrund. Any hints?

• Das Drängeln von Apple in Bezug auf die iCloud nervt. Sehr. Warum ist die Synchronisierung für den Schlüsselbund nach dem Upgrade aktiv?

Nach längerer Zeit brauchte ich mal wieder Deepl für eine Übersetzung. Ich wollte eine Rezension weitergeben, nichts Größeres, drei gesetzte Seiten aus einer französischen Zeitschrift. Politikwissenschaft. Elf Absätze. Deepl verlangte diesmal, dass ich mich registrieren möge. Was ich freilich nicht tat. Also rüber zu Google Translate: Desselbigengleichen. Die Phase der Monetarisierung hat begonnen. Es folgen neue Ausweichbewegungen.

Am Ende blieb die Übersetzungsfunktion in Firefox. Die freilich auch noch nicht so leicht konfigurierbar ist, wie ich es gerne hätte. Eine Übersetzung aus dem Französischen ins Deutsche setzt voraus, dass man nicht mit einer französischen Lokalisierung surft. Musste ich also temporär herausnehmen. Dann übersetzen. Und Französisch wieder rein. Wieder so eine Ausweichbewegung.

Was die Qualität der Übersetzung angeht, so decken wir darüber am besten den Mantel des Schweigens.

CRE.FM zu Git aus dem Jahr 2009 gehört. Man merkt, dass sich in dem Bereich kaum mehr etwas getan hat. GitHub war am Aufkommen, Wikipedia und „die Wikis“ waren immer noch ziemlich präsent, aber immer noch viel mehr als „etwas Neues“ als man es heute beschreiben würde.

Interessant fand ich an mehreren Stellen den Hinweis auf den Zusammenhang zwischen der Technik, dem Umgang damit und den gesellschaftlichen Auswirkungen. Das Forken wurde von einer regelrechten Kampfansage mit hingeworfenem Fehdehandschuh zu einer geradezu erwünschten Kulturtechnik, die jederzeit grundlegende Änderungen am Bestand ermöglicht und damit Spielräume öffnet. Das Forken als praktizierter Liberalismus. Sire, geben Sie Forkfreiheit!

Nicht weiter verfolgt wurde leider die Idee, dass es nachteilig war, Wikipedia in einem zentralen Repository zu belassen, wenn alle Welt sonst dezentral arbeitet. Noch heute wird der Fork von Wikipedianern im alten Sinne als ein Kampfbegriff verstanden, eher als eine Drohung als eine Chance, eine Entwicklungsmöglichkeit. Die Probleme beim Forken von Wikipedia wurden immer größer mit der Zeit, weil die Erweiterungen im Umfeld, vor allem die Integration von Wikidata, aber auch schon die zentrale Auslagerung aller Bilder auf Wikimedia Commons, einen eigenen Weg, der davon getrennt verliefe, kaum noch zulässt. Wikipedia ist als Dump nicht mehr standalone weiterzuverwenden. Es ist kaum zu ermessen, was diese im Laufe der Jahre geschaffenen Tatsachen für die Entwicklung von Wikipedia und für die Community bedeutet haben. Die Inselstellung dürfte sich dadurch verschärft haben. Die Isolation, die uns vom Rest des Webs trennt. Brücken zu den dezentralen Strukturen kann auch Wikidata nur formal aufbauen, nicht mehr inhaltlich.

Der Diff und der Umgang damit ist ein zentrales Instrument der Content-Entwicklung, das in seinen gesellschaftlichen und kulturellen Auswirkungen viel zu wenig beachtet wird. In Blog-Systemen spielt es auch kaum oder gar keine Rolle.

Form follows function. Content follows medium.

Das Usenet lebt, ein bisschen. Als Bram Moolenar starb, gab es dort eine Diskussion über die Rolle, die vi(m) derzeit (noch) spielt. Keine Frage, dass die Bedeutung, die so ein mächtiges technisches Werkzeug spielt, immer schon erheblich war, las man zum Beispiel schon anhand der Geschichte der nettime-l-Mailingliste. Aber als der Tod des Hauptentwicklers von vim bekannt wurde, wurde man in de.comp.editoren doch auch ziemlich nachdenklich und merkte ziemlich schnell, dass auch die Wahl des Editors eine Generationenfrage ist:

Wobei ich den Eindruck habe, dass bei den jüngeren Leuten vim nicht so beliebt ist. Da dominieren nano und Visual Studio Code.

Andererseits:

Die klicken oder wischen bloß noch rum.

Auch mit Word …

… sind viele der heutigen Studenten vermutlich schon überfordert. ;-)

Geschichten vom Älterwerden.

LibreOffice schafft die Begriffe Schusterjungenregelung und Hurenkinderregelung in seiner Bedienoberfläche ab, weil es die Begriffe bei Microsoft Word und bei Adobe InDesign auch nicht mehr gebe. Es handele sich um einen Drucker-Jargon, der für Joe Sixpack unverständlich sei. Das sind typografische Grundbegriffe. Kann man sich nicht ausdenken. Aber im heutigen Daily-Build schon so umgesetzt.

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.

Das Bloggen hat sich verändert. Weil sich die digitale Öffentlichkeit verändert hat. Menschlich. Immer mehr Gift ist im Umlauf. Aber auch technisch, weil es weggeht von dem großen Player WordPress. Gutenberg hat dann doch einige zum Nachdenken gebracht. WordPress ist nicht mehr in erster Linie für Blogger da. Und es gibt Alternativen. Erst an WordPress orientiert. Mittlerweile immer öfter: Statische Seiten. Generator: Pandoc in den Metadaten. Oder gleich ein Webhosting bei GitHub Pages.

Übergänge auch bei der Hardware sind zu erkennen: Einstige Apple-Fans sind zu Chromebook und zu Framework gewechselt, und sie sind zufrieden damit.

Übergänge bei den digitalen Räumen: Das Tor-Projekt hat die Mailingliste Tor-Talk geschlossen und bietet zur Diskussion ein eigenes Webforum an, das seit Juni selbst gehostet wird. Die Mailingliste Nettime-l hat sich dagegen konsolidiert und läuft unter neuer (menschlicher und technischer) Orga weiter, worüber große Erleichterung einkehrte. Am Rande der Neuaufstellung und vor dem Hintergrund des Tods von Bram Moolenaar erzählten Ted Byfield und Felix Stalder über die Bedeutung, die vim für die Moderation der Liste über einen so langen Zeitraum hatte.

Beim Org-Mode werde ich auch weiterhin nur die Outliner- und die Publisher-Funktionen nutzen und mein Projektmanagement in Thunderbird belassen. Die Bedienung ist mir bei der Zeit- und Terminverwaltung in Org-Mode nicht eingängig genug. Das lenkt einen zu sehr vom Inhalt ab. Dann lieber ein anderes Tool, das auch funktioniert, zumal man auf Bugreports derzeit bei Thunderbird sehr schnell reagiert.

Damit wäre der Umstieg von Aquamacs auf Emacs 29.1 abgeschlossen.

Zu den Features, die in Emacs 29.1 nicht out of the box funktionieren, zählt die Rechtschreibprüfung Flyspell. Je nach Emacs-Version und Betriebssystem sind verschiedene Anleitungen und Diskussionen zu finden. Unter macOS Ventura funktionierte bei mir folgendes:

• Aspell über Homebrew nachinstallieren.
• Load Path und Exec Path setzen (zu Wörterbuch und zu aspell).
• $LANG in Emacs setzen. Die Locale wurde zwar schon von macOS richtig gesetzt, Emacs bekommt davon aber nichts mit.
• $LANG und auch die restliche Locale müssen auf de_DE zeigen, und auch das Language Environment muss German sein, sagt das Emacs Manual. Sonst funktioniert LuaTeX nicht.
• Und nun Flyspell als Minor Mode für die Text Modes aktivieren.

(add-to-list 'load-path "/opt/homebrew/bin/")
(setq exec-path (append "/opt/homebrew/bin/" exec-path))
(add-to-list 'load-path "/opt/homebrew/Cellar/aspell/0.60.8/lib/aspell-0.60")
(setenv "LANG" "de_DE.UTF-8")
(set-locale-environment "de_DE")
(set-language-environment "German")
(add-hook 'text-mode-hook 'flyspell-mode)

M-x flyspell-mode

Welcome to Flyspell.

Es gibt widersprüchliche Ratschläge darüber, wie man Flyspell mit mehreren Sprachen zum Laufen bringt – vorstehend sehen wir nur eine Locale. Da es nicht die Locale des Systems ist, können wir sie ändern, ohne dass es weitere Auswirkungen hat. Man kann also beispielsweise das Wörterbuch für Englisch oder für Esperanto statt für Deutsch einbinden, in dem man de durch en oder eo ersetzt. Dann muss Emacs neu gestartet werden, ein erneutes Laden des Init Files reicht nicht aus. Das funktioniert aber nur für eine Sprache, nicht für mehrere. Still digging!

Update vom 20. August 2023: In der ursprünglichen Fassung des Blogposts hatte ich eine unvollständige Lösung vorgeschlagen. Ein Update von dtk.cls zwang mich gestern, weiter zu graben. Da dtk.cls seit neuestem LuaLaTeX erzwingt, stieß ich auf ein Problem, das, wie eine Suche auf StackExchange ergab, zwar seit längerem schon bekannt ist, mich aber noch nicht erreicht hatte. Wahrscheinlich hatte mich der alte Aquamacs bisher davor bewahrt.

LuaTeX ist etwas zickig und möchte die Locale beim Aufruf mitnehmen. Was unproblematisch ist, wenn man es aus dem Terminal aufruft. Beim Aufruf aus dem Editor heraus, muss es aber in der dortigen Shell ebenfalls eine Locale geben, mit der LuaTeX etwas anfangen kann, und das ist bei Emacs ebenfalls nicht out of the box der Fall. Es reicht also nicht, $LANG in der .emacs zu setzen, es braucht auch eine Locale und, so das Manual, ein passendes Language Environment in Emacs.