Hauptmenü
Sie sind hier
KOMAScript und xkeyval
Ich schreibe gerade an Klassendateien für unseren Lehrstuhl. Optionen möchte ich dabei nach dem Schlüssel-Wert-Prinzip anbieten, wie es auch die KOMAScript-Klassen jüngst anbieten. Das Paket xkeyval scheint mir recht geeignet für meine Zwecke zu sein. Es hat sich jedoch gezeigt, dass einige KOMAScript-Versionen (v2.95b) inkompatibel zu xkeyval sind; die aktuelle Version (v2.98) scheint aber mit xkeyval kompatibel zu sein, soweit ich das auf die Schnelle testen konnte.
Beim Studieren von scrkbase.dtx fiel mir auf, dass zwar das Paket keyval geladen, in der Codedokumentation aber immer wieder von xkeyval gesprochen wird. Zusätzlich habe ich gesehen, dass ein umfangreiches Sammelsurium an Makros zur Optionsverarbeitung implementiert wurde, das sich zum Teil auch mit Funktionalitäten des xkeyval-Pakets deckt.
Nun meine Fragen:
- Was waren die Gründe, dass ihr euch für keyval und gegen xkeyval entschieden habt.
- Wird KOMAScript in Zukunft weiterhin kompatibel zu xkeyval bleiben?
- Auf was sollte ich damit für die eigenen Klassen aufsetzen? Kann ich die KOMAScript-Funktionen (und damit den KOMA-Namensraum) verwenden?
Über eine Diskussion zu diesem Thema würde ich mich freuen.
Grüße
Aktuelle KOMA-Script Release
Die aktuelle KOMA-Script-Release finden sich primär im Dateien-Bereich des Projekts KOMA-Script auf SourceForge.
Schnelle Bugfixes und Prereleases finden sich im KOMA-Script-Repository.
Näheres zur aktuellen und früheren Releases ist dem Beitrag »Welches ist die aktuelle KOMA-Script-Release und wo finde ich sie?« zu entnehmen.
Beispiele aus der 7. Auflage des KOMA-Script-Buchs
Hingucker
Sponsoren
In der Reihenfolge der Spendeneingänge:
2024
Paul Kloß u. a.
2023
Paul Kloß, Manuel Kuehner, Martin Bierbaum, Ulrich Groh, Elke Schubert u. a.
Näheres zu Kosten und Betrieb ist in einem Blog-Beitrag zu finden. Natürlich sind auch Spenden ohne Namensnennung möglich.
Newsfeeds
KOMA-Script ist inzwischen kompatibel zu xkeyval
Was lediglich bedeutet, dass man xkeyval zusammen mit KOMA-Script verwenden kann. Das sollte eigentlich seit Version 2.96 der Fall sein.
Dass xkeyval von KOMA-Script nicht verwendet wird, hat drei Gründe.
KOMA-Script wird, wenn ich nicht etwa verbocke bzw. neue Böcke in xkeyval übersehe und xkeyval halbwegs kompatibel zu keyval bleibt, kompatibel zu xkeyval bleiben. Das wird schon deshalb so sein, damit Pakete, die xkeyval verwenden, auch weiterhin mit KOMA-Script verwendet werden können.
Die KOMA-Script-Funktionen für Optionen sind derzeit noch nicht dokumentiert und haben daher Beta-Status. Das heißt, dass sie sich noch ändern können. Außerdem sollte man keine eigenen keyval-Optionen anlegen, die den keyval-Namensraum "KOMA" bzw. "KOMA" verwenden. Theoretisch kann man die Anweisungen, die nicht zwingend Namensraum verwenden, nutzen. Das wäre beispielsweise
\KOMAProcessOptions, wenn man als optionales Argument etwas anderes alsKOMAangibt. Solange diese Anweisungen aber Beta-Status haben, geschieht ihre Verwendung auf eigenes Risiko.Es ist übrigens geplant, scrkbase irgendwann in zwei Pakete aufzuteilen, wovon eines dann die Anweisungen enthält, die auch für andere Klassen- oder Paketautoren nützlich sind, und eines die Teile, die nur für KOMA-Script-Klassen und -Pakete zuständig sind. Vermutlich werden genau dann auch die Anweisungen, die in dem allgemeinen Paket landen, dokumentiert werden – die anderen nicht bzw. nur in der dtx-Datei für den internen Gebrauch.
BTW: Du brauchst mich nicht mit dem Pluralis majestatis anzureden. Zwar ist KOMA-Script ein Nachfolger von Script 2 und enthält deshalb eventuell auch noch Code davon (viel kann es aber nicht mehr sein), aber seit KOMA-Script bin ich der einzige, der Implementierungsentscheidungen trifft und umsetzt.