Folgendes passiert, wenn man versucht, xparse in ConTeXt Mark IV (LuaTeX) zu verwenden
\input expl3-generic
\input xparse-generic
\starttext
\NewDocumentCommand\hello{om}
{
\IfNoValueTF{#1}
{Only #2}
{#1 and #2}
}
\hello{foo} \hello[bar]{foo}
\stoptext
Anstelle von "Nur foo bar und foo" erscheint "@ traceoff@traceon Nur foo @ traceoff@traceon bar and foo".
Fehlerdatei.pdf
Der Code erwartet, dass @ einen Catcode-Buchstaben hat. Das Folgende funktioniert also, aber ich weiß nicht, wie viel von xparse im Kontext tatsächlich funktioniert - die Idee von Befehlsdefinitionen und Syntax ist hier ganz anders.
~~~~
\input expl3-generic
\catcode \@=11
\input xparse-generic
\catcode
\@=12
\starttext
NewDocumentCommand\hello{om}
{
\IfNoValueTF{#1}
{Nur 2}
{#1 und #2}
}
\hello{foo} \hello[bar]{foo}
\stoptext
~~~~
xparse-generic
ist ein Platzhalter für bevorstehende Änderungen: Es wurde nicht mit reinem TeX oder ConTeXt getestet, daher überrascht es mich nicht, dass es hier fehlschlägt. Das dürften wir im Herbst wahrscheinlicher haben.
Ich bin sehr froh, dass das überhaupt funktioniert: Für ConTeXt müssen wir wohl \start...
/ \stop...
Umgebung einrichten.
Ich habe über die Kompatibilität mit ConTeXt gelesen, also teste ich es für den Fall, dass es irgendeine Art von kreuzkompatiblem Code gibt, da MkIV seine eigene idiomatische Behandlung optionaler Argumente hat ( \dosingleempty
, \dodoubleempty
, etc). Ich freue mich auch.
Bis vor kurzem war xparse
ein reines LaTeX2e-Paket. Das meiste davon werden wir im Herbst zu expl3-generic
, dann wird es Teil des plattformneutralen Angebots sein, aber es gibt keine Pläne, das Idom „neutraler“ zu machen. Natürlich verwendet ConTeXt weiterhin hauptsächlich Argumente vom Typ o
- und m
.
@JairoAdelRio Vor einiger Zeit habe ich eine Art Kompatibilitätsschicht geschrieben, um xparse
sowohl in Plain als auch in ConTeXt für das scontents
Paket zuzulassen (https://github.com/pablgonz/scontents). Vielleicht kannst du da ein paar Ideen (nicht sicher wie gut sie sind ;-) aufnehmen.
Zu der Zeit war xparse
vollständig in xparse.sty
, ein Großteil der Kompatibilitätsschicht definiert \ProvidesPackage
und so weiter. Heutzutage wäre es mit xparse-generic
viel einfacher, aber das wird sich wahrscheinlich in zukünftigen Versionen ändern, also würde ich wenn möglich etwas warten
Ich denke, der Punkt von @u-fischer ist richtig, und die bevorstehende Zusammenführung mit expl3
sollte mehr Dinge ansprechen: Ich schließe.