4

I don't get space-observing look-aheads right. What am I doing wrong here?

\documentclass{article}
\usepackage{expl3}
\begin{document}
\ExplSyntaxOn
\cs_new_protected:Npn \testInNormalLaTeXSyntax #1
  { \intern: #1 }
\cs_new_protected:Nn \intern:
  {
    \peek_charcode:NTF A
      { (next~token~is~A)~ }
      { 
        \peek_charcode:NTF ~
          { (next~token~is~space)~ }
          { (next~token~is~neither~nor)~ }
      }
  }
\ExplSyntaxOff

Hello, world with spaces!\\
\testInNormalLaTeXSyntax{AA}\\
\testInNormalLaTeXSyntax{bA}\\
\testInNormalLaTeXSyntax{ A}
\end{document}

White the first test works (AA), but the code line \peek_charcode:NTF ~ breaks things.

  • 2
    That is the exact same thing as writing \foo so the spaces is “gobbled”. May be you want \c_space_token? – Manuel Sep 13 '14 at 20:00
  • @Manuel, that's it! I was thinking so complicated and the answer was so simple. Make your comment an answer and I'll tick it. – mh543 Sep 13 '14 at 20:34
4

That ~ is nothing more than a space, and it works exactly like always: \foo \bar is the same as \foo\bar

In that case what you are looking for is \c_space_token, which is a stored space token, thus

\peek_charcode:NTF \c_space_token 

should work.

  • 1
    Perhaps not that ~ is specifically excluded from being an N-type argument – Joseph Wright Sep 13 '14 at 21:00
  • @JosephWright I'm not sure what do you mean… It's not “specifically excluded” but “generally excluded” (as any space token after a control sequence), or you mean something different? If you want a tokenized space you need something like, e.g., \use:nn { \token_new:NN \c_space_token } { ~ }. – Manuel Sep 13 '14 at 22:31
  • 1
    Spaces (~) and grouping braces ({ and }) are not N-type arguments and so should never be expected to work as such. That's the reason that we have \peek_after:Nw and \exp_after:wN and not :NN signatures, for example. So \use:nn { \token_new:NN \c_space_token } { ~ } is still formally forbidden, even though it would work at present. – Joseph Wright Sep 14 '14 at 7:11
  • Okey, I understood. N are never {, } or ~ (space), in case those will be expected in an argument, that argument will be w. Then \cs_set_eq:NN doesn't need the =~ but only = in its definition. And \token_new:NN should be \token_new:Nw, shouldn't it? – Manuel Sep 15 '14 at 16:33
  • I raised the business about \cs_set_eq:NN with the team. Position there is simple: only N-type args are allowed, and the =~ in the definition is something that might change. On \token_new:NN, the entire token module is a bit of a mess: we haven't yet got to a point where we know what is really needed! I'd say 'expect changes'. – Joseph Wright Sep 15 '14 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.