Hallo Markus,
habe eben die neuste KOMA-Version per tlmgr update --all "bekommen" - Danke sehr!
Das \renewcaptionname-Problem ist behoben, aber sobald ich das datatool-package lade gibt's ne "TeX capacity exceeded ..." Ferhlermeldung. Ich weiß zwar nicht inwiefern das jüngste KOMA-Update dafür verantwortlich seien könnte, wollte es aber trotzdem melden.
Dieser Code hier funktioniert fehlerfrei, solange datatool nicht geladen wird. Hinweis: Ich nutze lualatex als Compiler.
Viele Grüße
MM
\documentclass[version=last ]{scrlttr2} %]{scrartcl} %\usepackage{scrletter} \usepackage{datatool} \usepackage[% main=ngerman, %english, british, american, french, ]{babel} \renewcaptionname{ngerman}{\enclname}{Anlage} \begin{document} \begin{letter}{% Kunde }% \opening{Sehr geehrter Kunde,} das gewünschte Angebot finden Sie in der Anlage. \closing{Mit freundlichen Grüßen} \encl{Angebot} \end{letter} \end{document}
Danke
Das Problem tritt bereits mit:
bzw auch mit
auf, also sobald fp nach scrlfile geladen wird. In dem Fall entsteht eine Rekursion innerhalb des
\AtEndOfPackage
Hooks von fp. Seltsamerweise passiert das bisher nur bei diesem Paket. Und seltsamerweise passiert das, obwohl das Paket gar kein\AtEndOfPackage
verwendet.Ursache ist der Workaround, den ich für ein Unsauberkeit im LaTeX-Kernel in scrlfile eingebaut habe.
hmm, trotz 3.27a.3269 leider keine Besserung
Beseitigt man den Tippfehler im ersten MWE (datatool, ohne s), klappts dennoch nicht: "TeX capacity exceeded ..."
In der Hoffnung, dass es irgendwie hilfreich ist, füge ich unten das Log zu Deinem zweiten MWE ein:
Oh Mann!
Oh Mann, bin ich blöd. Bei den vielen Änderungen an meiner Testdatei habe ich irgendwann fp vor scrlfile geladen. Dass es damit funktioniert, ist nicht sonderlich verwunderlich. OK, ich werde den Workaround für das LaTeX-Problem deutlich aufbohren müssen. Mal sehen, was mir dazu einfällt.
Jetzt aber
Die sehr ausführliche Testdatei:
Läuft jetzt bei mir einwandfrei durch und ergibt IMO auch das erwartete Ergebnis (relevanter Ausschnitt aus der log-Datei:
Wenn da jetzt noch immer ein Fehler drin sein sollte, werde ich den heute sicher nicht mehr beheben. Ich habe heute noch nichts gegessen und heute Abend noch einen Termin. Dann geht es eben morgen weiter.
Alles bestens!
Besten Dank!
Verschachteltes Laden
Hallo,
meines Erachtens liegt das am verschachtelten Laden der einzelnen fp-Pakete untereinander. Ich habe das mal auf ein MWE zusammengefahren:
In dem Beispiel lädt das Paket
test-base.sty
das Pakettest-sub.sty
, welches wiederumtest-base.sty
lädt. Das verschachtelte Laden führt dazu, dasstest-base.sty-h@@k
bereits intest-sub.sty
zu\@undefined
gesetzt wird, was dann beim Aufruf von\ProcessOptions
zum besagten Fehler führt.Ja
Es ist eben schwer, um eine seltsame Implementierung im LaTeX-Kern herum zu programmieren. Ich habe jetzt einen komplett anderen Ansatz für den Workaround gewählt. Damit wird nun kein interner Hook von LaTeX mehr benötigt. Dafür ist es etwas umständlicher. Das war vor allem notwendig, damit es (hoffentlich, denn derzeit noch ungetestet) weiterhin mit dem Paket filehook funktioniert, das scrlfile nachprogrammiert.
Bei der Gelegenheit habe ich aber auch gleich noch eine Latte überflüssiger Gruppen entfernt.
Siehe auch
Danke übrigens für das schöne Beispiel. Ich habe das jetzt in leicht abgewandelter Form in in der Diskussion im LaTeX-Bugtracker dazu verwendet zu zeigen, dass das derzeitige Verhalten von LaTeX tatsächlich ein Bug ist und mein Wunsch nach einer Änderung nicht nur eine Bitte um eine Erweiterung ist. Das Problem kann bei Verschachtelungen, wie Du sie hier gezeigt hast, nämlich tatsächlich zur Vernichtung von
\AtEndOfPackage
-Code führen, so dass dieser niemals ausgeführt wird.Ich bin jetzt gespannt, ob der vielleicht etwas zu vorzeitig als Enhancement geschlossene Bug-Report von Enhancement zu Bug hochgestuft wird. IMHO wäre hier sogar eine Behebung im Rahmen der Patchlevel – so es noch einmal einen geben sollte – angebracht, statt es nur für die Beachtung bei einer 2020er-Release vorzumerken.
Wenigstens sollte aber der nächsten KOMA-Script-Release (bzw. mit der aktuellen Prerelease) die Verwendung von
\AfterPackage!
innerhalb eines Pakets als Workaround für den LaTeX-Bug (ich nenne das jetzt einmal so, auch wenn es noch nicht anerkannt ist) funktionieren.Danke ...
... für diesen kleinen Einblick hinter die Kulissen der Latex-Entwicklung. Deine Prognose ist eingetreten - es wurde zum Bug hochgestuft.
Letztlich auch egal
Hauptsache es wird beseitigt.
Wie das Ganze zeigt, ist es aber durchaus sinnvoll Bugs zu melden. Bei genauerer Betrachten können sie tiefer liegen und größere Auswirkungen haben, als man denkt.
Aha
Laut Frank ist das Vorgehen von fp, dass fp Unterpakete lädt, die ihrerseits fp laden, außerhalb der ursprünglichen Spezifikation für
\RequirePackage
.Nunja...
Ich hab da auch mal meinen Senf dazu gegeben. Prinzipiell könnte es ja auch sein, dass die beiden Pakete von unterschiedlichen Personen entwickelt werden und dennoch voneinander abhängig sind, sich also gegenseitig laden. Dann besteht das Problem ja weiterhin.