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

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

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