References: <5701B0C1.9080407@free.fr> <57022D60.6050803@morningstar2.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
            Icedove/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Message-ID:  <57028BA4.7010102@free.fr>
Date:         Mon, 4 Apr 2016 17:43:32 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: "Julien RIVAUD (_FrnchFrgg_)" <frnchfrgg@FREE.FR>
Subject: Re: Bug in xparse r, or R, or d or D argument specifiers
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <57022D60.6050803@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

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: <snip>
>
> 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.