-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow non-character brace tokens in xparse argument specification #46
Comments
Is this actually used in any packages? It seems like it would add a lot of complication to argument parsing... |
I am not aware of any real-world use cases, its just that xparse documentation always talks about "tokens", not individual characters, so I figured out that things like By the way, xparse argument specifications may contain argument processors like |
Doing so required a rewrite of pegjs grammar use for parsing xparse argument specifications. Previously, a lot of things were modeled by an ArgSpec struct `Group`, but in the end those used in O,R,D and those for e,E,u required different behavior in many aspects, so the pegjs grammar now differentiate them via `group` and `collection`. Also, the ArgSpec does not have Group anymore, everything is parsed to an array of strings. This should fix siefkenj#46.
Until argspec's behavior was fixed, and while doing so, a support for multi-token stops was added. Also, now it properly supports macro delimiters (which was really just a by-product of applying uniform treatment to any logic related to finding braces). This fixes siefkenj#46.
Until argspec's behavior was fixed, and while doing so, a support for multi-token stops was added. Also, now it properly supports macro delimiters (which was really just a by-product of applying uniform treatment to any logic related to finding braces). This fixes siefkenj#46.
The code below should be expanded to
Arg is: 123
.The text was updated successfully, but these errors were encountered: