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

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Bug in xparse r, or R, or d or D argument specifiers

From:

Date:

Mon, 4 Apr 2016 02:09:37 +0200

Content-Type:

text/plain

Parts/Attachments:

 text/plain (87 lines)
 Hello, A command created with \NewDocumentCommand \foo { r\OPEN\CLOSE } { } seems to work fine, and grabs correctly its argument (even when there is nesting involved), but leaves OPEN at the beginning of the argument. The problem is in \__xparse_grab_D_aux:NNnN where you do:   \token_if_eq_catcode:NNTF + #1   {      }   {     \exp_after:wN \l__xparse_fn_tl     \token_to_str:N #1   } But of course \token_to_str:N #1 is several characters long. Suppose now that there was no nesting, i.e. we used \foo\OPEN hello\CLOSE. Then \l__xparse_fn_tl goes to   \tl_if_blank:oTF { \use_none:n ####1 }     { \__xparse_add_arg:o { \use_none:n ####1 } }     {       \str_if_eq_x:nnTF         { \exp_not:o { \use_none:n ####1 } }         { { \exp_not:o { \use_ii:nnn ####1 \q_nil } } }         { \__xparse_add_arg:o { \use_ii:nn ####1 } }         { \__xparse_add_arg:o { \use_none:n ####1 } }     }   #3 \l__xparse_args_tl where the blank test cannot succeed (####1 is \OPEN hello where \ is a letter so \use_none:n will only gobble that), and the \str_if_eq_x is also false, because \use_none:n ####1 gives OPEN hello (all catcode 12) and \use_ii:nnn ####1 \q_nil gives OEN hello\q_nil (all catcode 12) As a side note, I don't understand what this test is about: it can be true only when ####1 is two tokens, so only one token, and I didn't find a situation where \use_none:n didn't cut it (I tried loosing braces prevention, or loosing space prevention, I never made the test return true *and* the \use_none:n call be wrong). Of course here it doesn't matter, the many letters of the opening token make these fine mechanics go awry. So we call \__xparse_add_arg:o { \use_none:n ####1 }, so \__xparse_add_arg:n {OPEN hello} where it should have been \__xparse_add_arg:n {hello} Of course, you could decide that control sequences don't count as tokens in this case and update the documentation (as for me, I was sometimes bitten[1] by the restriction on single tokens for delimited arguments, so you see towards where I'm leaning). Sorry for the confuse message, it is far too late here for steady thoughts, and English is not my mother tongue Cheers, Julien "_FrnchFrgg_" Rivaud [1] iirc, it was to make enumitem overlay-aware in beamer while respecting the already existing syntax. So \begin{enumerate}[][enumitem options], where of course any of them can be present (in that order only according to what beamer does for its enumerate). I had to resort to grabbing the first optional argument, check if it began with <, and if so remove the trailing > and grab another optional argument. A bit ugly, whereas \NewDocumentEnvironment {enumerate} { d{[<}{>]} o } would have been beautifully clean. 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.