Emacs 30.0.92 Pretest ist heute veröffentlicht worden.

Herunterladen und entpacken muss man den Tarball unter macOS Sonoma auf der Kommandozeile, und man braucht pkg-config per Homebrew, damit alle Bibliotheken gefunden werden.

GNU Emacs 30.0.92 (build 1, aarch64-apple-darwin23.6.0, NS appkit-2487.70 Version 14.7 (Build 23H124)) of 2024-10-26

Es ist der zweite Pretest Release für Emacs 30.1; der Unterschied zur finalen Version sollte nicht mehr allzu groß sein.

Die Version läuft bisher unauffällig.

Emacs 30.0.91 Pretest ist heute veröffentlicht worden.

Herunterladen und entpacken muss man den Tarball unter macOS Sonoma, wir erinnern uns, auf der Kommandozeile. Und man braucht pkg-config per Homebrew, damit alle Bibliotheken gefunden werden.

GNU Emacs 30.0.91 (build 1, aarch64-apple-darwin23.6.0, NS appkit-2487.70 Version 14.6.1 (Build 23G93)) of 2024-09-12

Es ist der erste Pretest Release für Emacs 30.1, und die Liste der Neuerungen ist dementsprechend lang.

Die Version läuft bisher unauffällig. Ich schreibe sehr schön damit, und alles funktioniert.

Zu den Neuerungen, die mich beim Übergang von Thunderbird 115 zu 128 am meisten überrascht hatten, gehört eine Änderung im Kalender-Modul. Seit Version 128 ist es nicht mehr möglich, Termine, die in der Vergangenheit liegen, zu suchen und als Liste ausgeben zu lassen. Die alten Termine sind zwar noch im Kalender vorhanden, man kann aber nur noch auf sie zugreifen, wenn man im Kalendarium händisch zurückblättert, und erst dann erscheinen sie auch in der Trefferliste, die unmittelbar darüber dargestellt wird. Wenn man danach sucht. Die Einstellung, alle Termine zu filtern, wurde ersatzlos abgeschafft.

Freilich ist das eine erhebliche Einschränkung der Brauchbarkeit eines digitalen Kalenders, der immer auch als Archiv für alle möglichen Daten dient. Man hatte sich Notizen in den Terminen gemacht, hatte dort Kontaktdaten notiert oder aus E-Mails durch Umwandeln in einen Termin oder eine Aufgabe direkt übernommen. All das ist nicht mehr durch eine Suche im Kalender zugänglich.

Der Verlust hält sich in Grenzen. Im Thunderbird-Forum hatten sie schon seit dem 1. August über das Problem diskutiert, während ich es erst am 23. August bemerkt hatte. Dort hatte ein Benutzer eine Erweiterung für Thunderbird bereitgestellt, die die vollständige Durchsuchbarkeit wieder herstellt. Zitat:

Die Entwickler haben grundsätzliche Bedenken mit ’allen’ (=potentiell unendlich vielen) Terminen. Außerdem planen sie anscheinend einen Umbau des Kalenders. Da kann es etwas dauern, bis die Funktionalität wieder da ist.

In der Tat, denn Änderungen beim Kalender stehen dieses Jahr ausdrücklich nicht mehr auf der Roadmap. Es wird also mehrere Jahre dauern, bis der Kalender im Thunderbird wieder vollständig durchsuchbar ist. Es gibt nicht mal einen Bugreport dazu, jedenfalls habe ich keinen gefunden.

Ich habe es erst spät bemerkt. Aber jetzt weiß ich, dass ich mich auf den Kalender nicht mehr als Archiv verlassen kann, und das ist ein bisschen wie mit einem Kleidungsstück, bei dem man einmal bemerkt hat, dass es einen kratzt. Es kratzt dann auch noch, wenn es eigentlich gar nicht mehr kratzen sollte oder könnte. Weil es einen in der Vergangenheit einmal kratzen konnte, und diese Erinnerung hat sich ins Gedächtnis eingebrannt, als wäre es ein traditionelles Muster auf einem alten Tonkrug, der auf verworrenen und daher umso lieberen Wegen aus dem Altertum irgendwie doch noch zu uns gefunden hat. Und du willst dich auch nicht wirklich auf ein Plug-in aus einem Webforum verlassen, um dem abzuhelfen.

Ich bin froh, dass ich den digitalen Kalender immer nur nebenbei benutzt hatte. Mein Hauptkalender ist seit vielen Jahren schon ein schöner Timer aus dem Korsch Verlag, dem ich treu geblieben bin, seit ich ihn einmal auf der Frankfurter Buchmesse entdeckt hatte. Tatsächlich hatte ich ihn viele Jahre auch dort gekauft. Bis dann der Lockdown kam. Seitdem bestelle ich ihn schon im Sommer über meine Buchhandlung. Und von nun an wird es wohl besser sein, auch beim digitalen Kalender ganz zu Plain Text zu wechseln: Der Emacs Calendar, sehr wahrscheinlich ergänzt um Org-Mode, ruft. Endlich.

Raus aus den Datensilos!

Es mag vorkommen, dass einem die eine oder die andere Anmerkung auf der Emacs-Devel-Liste entgeht. Aber dann gibt es ja immer noch die wöchentliche Zusammenfassung der Emacs News von Sacha Chua. In der heutigen Ausgabe verlinkt sie einen Teil-Thread, in dem Eli Zaretskii vor wenigen Tagen ein großes Wort gelassen aussprach:

Sadly, the MS-Windows port of Emacs is basically not taken care of anymore. There are no active developers on board who seem to care about it, except yours truly. I see this in the (lack of) responses to Windows-specific bugs and issues reported to the bug tracker: no one chimes in, even if I deliberately leave a bug report without responses for many days. As my free time is severely limited, I only care about aspects that affect me directly (and the 64-bit build and GCC 14 are way outside that scope).

If no one comes forward and starts taking care of the MS-Windows issues, I’m very close to the decision of declaring the Windows build of Emacs „unsupported“, meaning anyone who needs it are „on their own“, from my POV as the (co)maintainer.

This is not an April 1 joke: if there’s a significant community interested in being able to run and develop Emacs on MS-Windows, someone should volunteer to take care of the build on a day to day basis, or else the conclusion is that there’s no general interest in that platform among the Emacs community that is high enough to justify the investment.

You have been warned!

Und das gilt nicht nur für den Windows-Port, sondern auch für den NextStep-Port, also für den Emacs unter macOS, ergänzte Arash Esbati:

My impression is that the statement above also applies to the NS-port.

Freilich fiel Richard Stallman himself noch mit seinem bekannten Standpunkt ein, man arbeite in erster Linie am GNU/Linux-System, und alles Proprietäre finde erst an allerletzter Stelle statt.

Aber wir sind jedenfalls gewarnt worden. Die Ausfälle unter macOS werden schon häufiger. Zum Beispiel funktioniert die Zwischenablage oft nicht, wie man es erwarten würde. Dazu hatte ich vor ein paar Wochen einen Bugreport geschrieben. Die Einschläge kommen also näher.

Am Ende könnte sogar Jörg Kantel recht haben, wenn er es ablehnt, sich auf Org-Mode einzulassen, weil der letztlich an Emacs hänge, und wer weiß, wie lange es den überhaupt noch gebe. Raus aus den Datensilos …

Es bleibt sehr zu hoffen, dass sich in der nächsten Zeit wieder Entwickler finden werden, die Spaß daran haben, Emacs auf proprietären Plattformen aktuell zu halten.

Nach einer längeren Diskussion hat Tassilo Horn heute Morgen bekanntgegeben, dass AUCTeX, die Entwicklungsumbegung für (La)TeX in Emacs, nicht mehr als Tarball verteilt werde. AUCTeX kann seitdem nur noch über das Archiv ELPA bezogen werden. AUCTeX 13.3 war demnach die letzte Version, die es noch als Tarball gab. Die aktuelle Version ist AUCTeX 14.0.6.

Hi all,

from now on, AUCTeX releases are only made through the Emacs Lisp Package Archive [1], so auctex-13.3 is the last standalone tarball release. Distro packagers are encouraged to use the ELPA packages as-is and install them under one of the new Emacs locations for system-wide packages, see `package-directory-list’.

At the same time, development is now done on the „main“ branch and the „master“ branch has been deleted. Its last state has been pushed as „auctex-13“ branch for archiving purposes but it won’t get any updates anymore.

For users who tracked the master branch: do „git switch main“ to switch to the main brach where development takes place nowadays.

Bye, Tassilo

[1] elpa.gnu.org

Für die meisten Benutzer ändert sich dadurch in der Praxis nichts. AUCTeX ist weiterhin nicht Bestandteil von Emacs und muss daher nachinstalliert werden. Wer AUCTeX, wie üblich, über den Paketmanager package.el aus ELPA installiert hatte, wird von dort auch weiterhin Updates erhalten. Wer bisher die Entwicklerversion bezogen hatte, kann per git switch main von master zu main wechseln. Der Branch auctex-13 wurde heute zum Archiv.

Emacs 29.4 ist heute veröffentlicht worden. Und with a little help from my friends gelang es mir, auch die letzten Unzulänglichkeiten beim Kompilieren unter macOS Sonoma zu beseitigen.

Entpacken muss man den Tarball nun auf der Kommandozeile. Aber erst wenn man pkg-config per Homebrew installiert, werden alle Bibliotheken gefunden.

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

Das Upgrade ist auch diesmal sehr zu empfehlen, in den Release Notes heißt es:

* Changes in Emacs 29.4
Emacs 29.4 is an emergency bugfix release intended to fix the
security vulnerability described below.

** Arbitrary shell commands are no longer run when turning on Org mode.
This is for security reasons, to avoid running malicious commands.

Damit einher geht der Release von Org Mode 9.7.5, der ebenfalls eingespielt werden sollte. Der Bug, um den es geht, besteht seit Org Mode 7.9 = Emacs 24.2. Betroffen sind also beispielsweise auch alte Installationen von Aquamacs Emacs.

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?

GNU Emacs 29.3 ist heute veröffentlicht worden. ./configure – make – make install lief unter macOS Ventura problemlos durch.

GNU Emacs 29.3 (build 1, aarch64-apple-darwin22.6.0, NS appkit-2299.77 Version 13.6.5 (Build 22G621)) of 2024-03-24

Der Programmstart ist ein bisschen umständlich, weil man erst den Paketinhalt des Programms anzeigen lassen und dann /Applications/Emacs.app/Contents/MacOS/emacs per Kontextmenü öffnen muss. Bisher alles wie gehabt.

Das Update ist diesmal sehr zu empfehlen:

Emacs 29.3 is an emergency bugfix release intended to fix several security vulnerabilities described below.

• Arbitrary Lisp code is no longer evaluated as part of turning on Org mode. This is for security reasons, to avoid evaluating malicious Lisp code.

• New buffer-local variable 'untrusted-content'. When this is non-nil, Lisp programs should treat buffer contents with extra caution.

• Gnus now treats inline MIME contents as untrusted. To get back previous insecure behavior, 'untrusted-content' should be reset to nil in the buffer.

• LaTeX preview is now by default disabled for email attachments. To get back previous insecure behavior, set the variable 'org--latex-preview-when-risky' to a non-nil value.

• Org mode now considers contents of remote files to be untrusted. Remote files are recognized by calling 'file-remote-p'.

Vergangenen Oktober hatte ich mich zuletzt mit dem in Emacs integrierten Wörterbuch dictionary.el und mit osx-dictionary beschäftigt, mit dem man auch das Wörterbuch in macOS in Emacs nutzen kann. Dann passierte lange Zeit relativ wenig in meiner dotemacs, weil mir dazu die Zeit fehlte. Letzteres ist derzeit eigentlich immer noch so. Aber manchmal ist es vernünftig, dem Impuls nachzugeben und sich einmal wieder der Emacs-Konfiguration zuzuwenden, weil es erholsam und gut ist, sie zu pflegen. Was noch fehlte, war eine echte Web-Suche, sowohl in der größten Enzyklopädie ever written als auch in einer Internet-Suchmaschine.

Die folgende Ergänzung habe ich heute mit kleineren Änderungen aus dem Blog von İsmail Efe Top (via jcs) übernommen. İsmail hatte dort ursprünglich eine Google-Suche für das Wort at-point formuliert. Ich habe das als eine Anregung genommen und für meine Zwecke leicht angepasst, weil es tatsächlich praktisch ist und eine schöne Ergänzung zu meiner Lexikon-Suche darstellt:

  (defun wikipedia-search-word-at-point ()
  "Search the current word on German Wikipedia using browse-url."
  (interactive)
  (let ((word (thing-at-point 'word)))
    (if word
        (browse-url (concat "https://de.wikipedia.org/w/index.php?search=" word))
      (message "No lemma found at point."))))
  (global-set-key (kbd "M-ä") 'wikipedia-search-word-at-point)

  (defun metager-search-word-at-point ()
  "Search the current word on MetaGer using browse-url."
  (interactive)
  (let ((word (thing-at-point 'word)))
    (if word
        (browse-url (concat "https://metager.de/meta/meta.ger3?eingabe=" word))
      (message "No term found at point."))))
  (global-set-key (kbd "M-Ä") 'metager-search-word-at-point)

Nachdem ich die Eingabe M-# schon für eine Suche des Terms at-point im Emacs-Dictionary und M-' entsprechend für die Suche im osx-dictionary belegt hatte, wählte ich M-ä für die Suche in der deutschsprachigen Wikipedia und M-Ä für eine ebensolche in meiner Standardsuchmaschine MetaGer. Die Ä-Taste wählte ich, weil sie direkt neben der anderen Taste angeordnet ist. Funktioniert sehr schön, wie erwartet.

Die Fallback-Lösung (eine Nachricht im Minibuffer) kommt nur zum Einsatz, wenn der Cursor beim Aufruf der Funktion nicht an einem Term steht, den er an den Server per browse-url übergeben könnte. Das Fallback-Handling im Übrigen verbleibt beim Server; man wird dann ja auch schon im Webbrowser sein, so dass man dort die Antwort erwartet.

AUCTeX 14 ist veröffentlicht worden. Leider gibt es ein Problem beim Upgrade. Das Setup läuft nicht sauber durch, wenn schon eine frühere Version von AUCTeX installiert und aktiv ist. Emacs friert ein und läuft mit einer Prozessorlast von 100 Prozent. In dem Fall hilft ein beherztes C-g, um die Endlosschleife zu verlassen.

Mittlerweile gibt es eine Bugfix-Version 14.0.2 auf ELPA. Man sollte aber weiterhin zunächst die ältere Version deinstallieren, und zwar auf demselben Weg, mit dem man sie zuvor installiert hatte. Standardmäßig wäre das der Emacs-eigene Paketmanager package.el. Gegebenenfalls sind zuvor zudem Abhängigkeiten zu entfernen, die auf AUCTeX beruhen, in meinem Fall war das company-auctex. Dann sollte die Installation von AUCTeX 14.0.2 von ELPA sauber durchlaufen.

Emacs  : GNU Emacs 29.2 (build 1, aarch64-apple-darwin22.6.0, NS appkit-2299.70 Version 13.6.3 (Build 22G436))
 of 2024-01-18
Package: 14.0.2

Danach die zuvor entfernten Abhängigkeiten wieder herstellen. Fertig.

Es wäre zu wünschen, dass bei künftigen Versionen nicht ohne weiteres davon ausgegangen wird, dass man eine Erstinstallation von AUCTeX vornimmt.