User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
References: <4A7921CF.5020803@morningstar2.co.uk> <4A8072A6.9080005@elzevir.fr>
            <4A807946.5060707@morningstar2.co.uk>
OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x50A89B42
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <4A8083E3.7080009@elzevir.fr>
Date:         Mon, 10 Aug 2009 22:32:35 +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: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <mpg@ELZEVIR.FR>
Subject: Re: xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <4A807946.5060707@morningstar2.co.uk>
Precedence: list
Status: R

Joseph Wright a écrit :
> 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 :-)
> 
Phew.

>> 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.
>>
I realise it would be more explicit with an example. A user wants to have her
(or his, cause actually the user is me in this example) table "headings"
centered and in boldface, whatever the current column specification is, so he
makes a command for this, using \multicolumn{1}{c}: it works, the user's happy.
 Later, he realises that sometimes the header should span many rows, so tries to
change his definition to

\newcommand*\hcell[2][1]{%
  \multicolumn{#1}{c}{\hcellfont #2}}

It fails miserably, with a "mispleced \omit" error. The point is of course that
the \omit should be the first unexpandable token in the cell, but \@ifnextchar
(or \peek_token_remove_generic:NTF in our case) involves quite a lot of
unexpandable primitives.

I remembered this problem today because a very similar question (involving
\@ifstar and \multicolumn) was asked in fctt.

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

AFAIK, the beginning of a cell in an alignment is a expansion situation and the
\protected doesn't help here.

Thinking of it, it's not only about peeking functions, but about the whole
parser, which should (optionally) work purely by expansion, so that no
unexpandable token appears before the development of the actual user macro, thus
allowing to define and effectively use macros involving \omit or \noalign.

With current \newcommand, the "parser" has this property if there is no optional
argument (for the simple reason that there is no parser in this case) and could
have it if \@testopt were replaced with eg \FE@testopt from etextools in other
cases.

My question is: is it doable/desirable to allow defining macros having this
property with xparse? It may involve a lot of changes in the implementation,
hence not be worth trying. However, I hope it was worth at least raising the
question.


Manuel.