LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 4 Apr 2016 17:43:32 +0200
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
Content-Type:
text/plain; charset=utf-8; format=flowed
From:
"Julien RIVAUD (_FrnchFrgg_)" <[log in to unmask]>
Parts/Attachments:
text/plain (71 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: <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.

ATOM RSS1 RSS2