LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Joseph Wright <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 10 Aug 2009 20:47:18 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (38 lines)
Manuel Pégourié-Gonnard wrote:
> I'd like to ask about one point, that was maybe discussed earlier: if so, please
> excuse me for not reading the archives first.

I don't recall it coming up in any of the xparse discussions I've read :-)

> Some argument specifiers imply peeking at the next token, using
> \peek_meaning_remove:NTF (or maybe charcode in the future, but anyway the
> unexpandable \peek_token_remove_generic_NTF at some point).
> 
> The point is that peeking doesn't work purely by expansion, and it will
> sometimes cause problems. A not-so-unfrequently-asked-question is about command
> with an optional argument trying to call \multicolumn in a table, ending with
> "misplaced \omit" error.
> 
> In the 2e world, people have proposed variants of \@ifnextchar "working" purely
> by expansion: there is at least xoptarg by Josselin Noirel and more recently
> \FE@testopt and \FE@ifstar in Florent Chevret's etextools. Of course those are
> not perfect and have their limitations, but those packages probably show there
> is an interest for such tests. (I've been using xoptarg in a few personal macros
> myself, and already considered implementing similar functionnality in xargs (but
> didn't have to come to a decision, since I'm not working on xargs atm)).
> 
> So, my question is: do you think it's worth proposing such a feature in xparse?
> Of course it would be optional (eg, accessed using a modifier before the
> argument specifier invloving peeking ahead) and the limitations of this approach
> should be properly documented (unlike xoptarg).
> 
> It would be quite a relief for authors wanting to define their personal macros
> to be used in tabs, but not wanting (or even able to) handle all the
> testing/argument-shuffling involved in writing the argument parser themselves.

Remember, though, that *everything* xparse makes is \protected. So a
function created with xparse will be trying to do \peek_<whatever> in an
expansion situation.
-- 
Joseph Wright

ATOM RSS1 RSS2