Latex3: xparse not working in ConTeXt MkIV

Created on 18 Jun 2020  ·  7Comments  ·  Source: latex3/latex3

The following occurs when one tries to use xparse in ConTeXt Mark IV (LuaTeX)

\input expl3-generic
\input xparse-generic
\starttext 
\NewDocumentCommand\hello{om}
{
    \IfNoValueTF{#1}
    {Only #2}
    {#1 and #2}
}
\hello{foo} \hello[bar]{foo}
\stoptext 

Instead of "Only foo bar and foo" it appears "@traceoff@traceon Only foo @traceoff@traceon bar and foo".
errorfile.pdf

bug generic-mode xparse

All 7 comments

The code expects @ to have catcode letter. So the following works, but I don't know how much of xparse actually works in context - the idea of command definitions and syntax is quite different here.

~~~~
\input expl3-generic
\catcode\@=11 \input xparse-generic \catcode\@=12
\starttext
NewDocumentCommand\hello{om}
{
\IfNoValueTF{#1}
{Only #2}
{#1 and #2}
}
\hello{foo} \hello[bar]{foo}
\stoptext

~~~~

xparse-generic is very much a placeholder for upcoming changes: it's not been tested with plain TeX or ConTeXt, so I'm not surprised it fails here. We are likely to have that more settled once we get to the autumn.

I'm very pleased this works at all: for ConTeXt, I guess we might have to add \start.../\stop... environment set up.

I've read about compatibility with ConTeXt, so I'm testing it in case there's some sort of cross-compatible code, as MkIV has its own idiomatic handling of optional arguments (\dosingleempty, \dodoubleempty, etc). I'm pleased, too.

Up to recently, xparse was purely a LaTeX2e package. We are going to merge most of it into expl3-generic in the autumn, at which point it will be part of the platform-neutral offering, but there are no plans to make the idom more 'neutral'. Of course, ConTeXt still uses o- and m-type arguments in the main.

@JairoAdelRio Some time ago I wrote some kind of compatibility layer to allow xparse in both Plain and ConTeXt for the scontents package (https://github.com/pablgonz/scontents). Maybe you can take some ideas (not sure how good they are ;-) form there.

At the time xparse was entirely in xparse.sty, so much of the compatibility layer is defining \ProvidesPackage and so on. Nowadays it would be a lot easier with xparse-generic, but this will likely change in future releases, so I'd wait a bit if possible

I think @u-fischer's point is right, plus the upcoming merge-to-expl3 should address more things: I'm closing.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

frougon picture frougon  ·  6Comments

dbitouze picture dbitouze  ·  4Comments

josephwright picture josephwright  ·  31Comments

dbitouze picture dbitouze  ·  8Comments

bastien-roucaries picture bastien-roucaries  ·  19Comments