## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: Bug in xparse r, or R, or d or D argument specifiers

From:

Date:

Mon, 4 Apr 2016 17:43:32 +0200

Content-Type:

text/plain

Parts/Attachments:

 text/plain (70 lines)
 Le 04/04/2016 11:01, Joseph Wright a écrit : > The intention of d/D/r/R was always as a generalisation of LaTeX2e's > optional arg/co-ordinate arg syntax. As such, my idea at least was that > the are intended for handling single character tokens (also true for > t-type args, etc.). Certainly xparse is meant to provide 'LaTeX2e-like > interfaces' not 'a completely general argument parser', so it's not > unreasonable to have a restriction here. I'll look to tighten up the > docs but will first wait to see if there are strong views that the > behaviour should change. Fair enough. If the behaviour doesn't change, I'll write my own grabber. (I have far simpler requirements, no brace conservation problem and no need to hide anything; I just wanted a cheap (as in work from me) way to get paired \IF/\ENDIF for rendering algorithms as AlgoBox[1] does) >> As a side note, I don't understand what this test is about: > > This was added by me in r4462 > (https://github.com/latex3/latex3/commit/5aa6ab78f1e035abd73daf41a92b30501bcd27a4). > As noted there, the case we are worrying about is the behaviour of the > two uses > > \foo[{bar}]{baz} > \foo[bar]{baz} Yes, I understood after my mail that you don't want to prevent brace removal at all times (then \use_none:n would be enough): you *want* to remove braces when encountering [{bar}] (e.g. for [{[}]), but a simpler approach could lead to space and braces removal in the [ {bar}] case (where you don't want it). >> \NewDocumentEnvironment {enumerate} { d{[<}{>]} o } would have been >> beautifully clean. > > Till's interface choice here is perhaps a bit unusual Of course, I don't really see why he didn't choose {d<> o} > but that doesn't mean xparse has to handle it directly. (As noted above, that's not > really what xparse is about.) I understand that you don't want too much complexity, but I don't agree with that statement:    - either xparse is only about LaTeX2e (and it is far too much complicated already)    - or it is about enabling the types of syntax found in the LaTeX 2e ecosystem (and thus the r() for pict2e, etc.) and I don't see where you draw the line (apart from the complexity argument). Beamer's default overlay specifications can be considered "common" (at least because beamer is the only presentation class I have seen used in the wild for quite a long time). Anyway, xparse is not my code, and more to the point not my maintenance burden, so that's not my call. >> P.S.: I also encountered a "quirk" in \NewDocumentEnvironment, in that >> the environment close is not align-safe (probably because of the >> retrieving of arguments, but I didn't check; or just because it is >> protected?): it starts a new row (and that's the least worry because >> then the closing stuff is in a box group and TeX frowns upon the >> \endgroup of \end). I didn't need closing args, so I just used >> \NewDocumentCommand. > > This looks like it needs a separate post with an example! Sure. I'll try and write an MWE. Cheers, Julien.